[sc34wg3] One standard or several?

[Bernard Vatant]

Just two points.

First: I agree with Jim that a single, multiple parts, Topic Maps
standard in the way to go. Since 13250 is now a well-known brand, let's
try to keep it the general umbrella, and if possible gather whatever
belongs under that.

Second: in that spirit, I wonder if at some point we should not consider
integration of "General Requirements and Recommendations on Published
Subjects" under that umbrella. I refer here explicitly to Deliverable 1
of OASIS PubSubj TC, which hopefully will be approved soon. The way we
have done it finally in the TC, separating the core concepts and
requirements from any specific structure, metadata, syntax or
application (those being to be developed in future deliverables), it
seems to me that it deserves integration in the Topic Maps standard
family. 

This is not something urgent, but to keep on the backburner, and figure
where it would be best to put that piece in the final (?) picture.

Bernard

============================================
Bernard Vatant
Knowledge Engineering
Mondeca - www.mondeca.com
OASIS Published Subjects Technical Committee
www.oasis-open.org/committees/tm-pubsubj
============================================

|-----Original Message-----
|From: sc34wg3-admin@isotopicmaps.org [mailto:sc34wg3-
|admin@isotopicmaps.org] On Behalf Of Mason, James David (MXM)
|Sent: mercredi 22 janvier 2003 21:26
|To: 'sc34wg3@isotopicmaps.org'
|
|I've already declared myself to be of the one standard, multiple parts
|school. If it defines Topic Maps, it ought to be one standard. If
something
|has to conform to it (whether for interchange syntax or interpretation
of
|what do do when one gets something in that syntax), it needs to be one
|standard.
|
|Lars Marius offers several options below. Like him, I think some of
them
|(particularly "a" and "b") are pretty bad. His "c" takes us back to
where
|we
|were in 2000. His "d" is where I thought we were headed until Charles
|started pushing the multiple standards bit. It's what we drafted the NP
|for,
|though we eventually checked a different box about what the results
should
|be. I agree that "e" would be a mess. I don't think we have an option
to do
|"f" (it's possible to turn a failed DIS into a TR, as WG2 did with Font
|Services, but not to turn a published IS into one).
|
|If what Lars Marius says in one of his most recent messages about the
|relationship of the current syntaxes to SAM and thence to RM is
accepted, I
|think we can get to "d" in steps. That is to say, we can publish the
SAM
|and
|RM, then revise the current 13250 and split it into syntax, tutorial,
|conformance, and whatever else. Until then, the current 13250 can stay
|where
|it is, and people can conform to it as best they can.
|
|I really don't like multiple standards, particularly if there are
strong
|dependencies among them. It's one thing to say, for example, that the
|interchange syntax for some data structure makes normative reference to
|UNICODE, a separate standard, and an entirely different sort of thing
to
|say
|that the semantics of an interchange syntax are in a standard with a
|different number.
|
|Jim
|
|
|-----Original Message-----
|From: Lars Marius Garshol [mailto:larsga@garshol.priv.no]
|Sent: Wednesday, January 22, 2003 10:32 AM
|To: sc34wg3@isotopicmaps.org
|Subject: Re: [sc34wg3] One standard or several?
|
|<snip>
|
|I liked the multipart approach because it seemed clean and easy, and
|because the components N323 proposes to put in a single standard all
|seem (to me) to belong in the core standard.  It's not a big deal for
|me, however.
|
|The problem I see with multiple standards is what is going to become
|of ISO 13250. These are the possibilities I can think of:
|
| a) Make the RM be 13250. This is likely to confuse people, as the
|    current 13250 and the RM are only distant relations of one
|    another, and other parts of the family are much closer to what
|    used to be 13250.
|
| b) Make the SAM be 13250. This has the same problem, although less
|    so.
|
| c) Make the HyTM syntax specification be 13250. This would make 13250
|    continue to specify the same thing, but it would no longer stand
|    on its own.
|
| d) Withdraw 13250, as it will be replaced by new and better
|    specifications.
|
| e) Keep 13250 pretty much as it is. This means turning what is
|    essentially a tutorial into a normative text with hairy relations
|    to the other standard. I think this option is technically and
|    editorially a horrible option, and find it very difficult to live
|    with.
|
| f) Keep 13250 pretty much as it is, but turn it into a technical
|    report that is basically a technical topic map tutorial, pretty
|    much like XTM 1.0, but with more explanations.
|
|Personally, I don't like any of these options, but I do think f) is
|the best choice, provided ISO procedure actually allows it. I think a
|multipart standard is much cleaner, and I don't think there is any
|difference in marketing between the two approaches.
|_______________________________________________
|sc34wg3 mailing list
|sc34wg3@isotopicmaps.org
|http://www.isotopicmaps.org/mailman/listinfo/sc34wg3