[sc34wg3] Backwards Compatability

[Lars Marius Garshol]

* 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.

--Lars M.