[sc34wg3] 1. Re: Backwards Compatability (Lars Marius Garshol)

Sam Hunting sc34wg3@isotopicmaps.org
Mon, 29 Oct 2001 15:35:12 -0800 (PST)


Passing over some novel views about how standards should be read, and
what votes in specifications bodies mean, to get to the essential point
...

--- sc34wg3-request@isotopicmaps.org wrote:
> Send sc34wg3 mailing list submissions to
> 	sc34wg3@isotopicmaps.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
> or, via email, send a message with subject or body 'help' to
> 	sc34wg3-request@isotopicmaps.org
> 
> You can reach the person managing the list at
> 	sc34wg3-admin@isotopicmaps.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of sc34wg3 digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Backwards Compatability (Lars Marius Garshol)
> 
> --__--__--
> 
> Message: 1
> To: sc34wg3@isotopicmaps.org
> Subject: Re: [sc34wg3] Backwards Compatability
> From: Lars Marius Garshol <larsga@garshol.priv.no>
> Date: 29 Oct 2001 16:49:07 +0100
> Reply-To: sc34wg3@isotopicmaps.org
> 
> 
> * Lars Marius Garshol
> |
> | I think we all agree that since the purpose of the foundational
> model
> | is to remove the ambiguities of those specifications, the removal
> of
> | some of these ambiguities will cause behaviour that before seemed
> | legal to now be illegal. This will be limited to minor issues of
> | processing, however, and not involve any changes to the XTM 1.0
> | model.
> 
> * Sam Hunting
> | 
> | As for the purpose that "we" all agree on -- I've missed the part
> of
> | the ISO minutes where this is stated. 
> 
> It's not in any formal SC34 document, but I was under the impression
> that this was what we all intended with the foundational model. If
> anone disagrees I'd like to know.
> 
> I did have <URL: http://www.y12.doe.gov/sgml/sc34/document/0235.htm >
> in mind when writing the above, though.
> 
> | As to models, the only "models" I know about that are relevant to
> | the ISO list are the "level 0" and "level 1" models. If there is a
> | model in XTM 1.0 it is either informative (the conceptual model and
> | Annex F) or implicit. 
> 
> There is an implicit model in XTM 1.0. Annex F also has processing
> requirements (made informative by, IMHO, mistake).
> 
> | Therefore, the phrase "changes to the XTM 1.0 model" assumes
> | precisely what is at issue -- that there is universal agreement on
> | what the XTM 1.0 model is.
> 
> To a large extent there is, but there are gray areas.
> 
> | It's very unclear to me, then, why ISO would initiate the level 0
> and
> | level 1 work items if indeed topic maps are "finalized." 
> 
> As I saw it it was because although topic maps were finalized there
> were areas of the specifications that were not entirely clear. I
> never
> saw the Berlin resolutions as a "go-ahead" for fundamental changes to
> the model.
>  
> * Sam Hunting
> |
> | The infoset is accepted by "all" the implementors? I'm not so sure.
> 
> 
> There may be implementors that do not agree with it (other than in
> minor details), but if so I am not aware of it. If anyone could point
> to implementors who disagree with it I'd be grateful.
>  
> | P.S. If people could stop referring to the XTM specification as a
> | "standard" (which implies that it has the same status as an ISO
> work
> | product) 
> 
> I don't think this is a very useful distinction, Sam. XTM 1.0 was
> obviously meant to be a specification that implementations were
> intended to conform very closely to. It is not an ISO standard, but,
> as far as I know, that was for practical reasons (mostly speed), and
> did not mean that it was to have lower status that ISO 13250.
> 
> | and if people could distinguish between the normative and
> | informative portions of the XTM 1.0 specification in discussion,
> the
> | clarity of our discussions would be greatly increased.
> 
> Again, I disagree. First of all, the status of annex F is ambiguous.
> It is listed as being informative, and yet there are normative
> references to it from normative text. So the spec is contradicting
> itself on this point.
> 
> Secondly, it was made informative instead of normative because Steve
> P.  (and I think also Graham) were unwilling to spend the time it
> would have taken to have a fight about whether it should be normative
> or informative. So at the time of publication there were groups of
> people wanting different things, and its current status is a kind of
> compromise.
> 
> The third point is that even if annex F were purely informative one
> should be able to use it to throw light on other parts of the
> specification. 
> 
> The fourth is that annex F is there, it's what people have
> implemented, and it's something that any user of the specification
> would be very unwise to ignore, even had it been purely informative.
> 
> So while it's status is somewhat ambiguous, it doesn't mean that we
> are free to completely ignore what it says.

.... which is to agree that indeed, no one has ever suggested that
"'we' are free to completely ignore what [Annex F] says." Did someone
suggest that?

S.

P.S One point.

[sam hunting questions]
> | The infoset is accepted by "all" the implementors? I'm not so sure.
> 
[lars]
> There may be implementors that do not agree with it (other than in
> minor details), but if so I am not aware of it. If anyone could point
> to implementors who disagree with it I'd be grateful.

Well, I'm going to assume that the statement is false until proven
otherwise.




=====
<!-- "Saving civilization through markup." -->

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com