[sc34wg3] Pre-publication draft of XTM 1.1 CD

[Lars Marius Garshol]

* Murray Altheim
| 
| I am curious as to why the 1.1 DTD is considered informative, i.e.,
| why it can't be considered normative.

That's actually a quite complicated story, but it has to do with all
the ways in which XML as an interchange standard is broken. We are
trying to work around those.

This issue was discussed by the committee:

<URL: http://www.ontopia.net/omnigator/models/topic_complete.jsp?tm=tm-standards.xtm&id=xtm-normative-schema >

The only background material I have on this is in the slides I've used
to present the various TMDM/XTM issues during committee meetings,
which I now see I haven't posted anywhere. If you want I can do it.

Basically, the reason is that if the DTD is normative it makes it a
bit difficult to define the XML application properly. Are you required
to use a validating parser? If not, what happens when someone leaves
out FIXED attributes? Are they valid or not? What happens when someone
gives you a valid XTM document with a broken DTD reference? What
happens if someone gives you a document which modifies the DTD in the
internal subset but validates correctly?

We realized that with RELAX-NG we could just say: an XTM 1.1 document
is syntactically valid if it *would* *have* validated against the
RELAX-NG schema in Annex A. All that's required of software then is to
verify this condition, which they can do in any way they want. (If you
have an equivalent DTD you can just use that, provided you work around
the problems with current DTD validating software.)

| I don't have any plans to use the RELAX-NG schema, hence I can't
| claim conformance if I only use the XTM 1.1 DTD. That doesn't seem
| quite right. I'd like to be able to validate using the DTD and claim
| XML syntax conformance to an ISO standard.

You can do that, so long as you get the same results, and since the
schema uses only minimal RELAX-NG-specific features you can easily get
the same results with a DTD. (You basically have to add minimal URI
validation, which any proper XTM implementation has to do anyway.)
 
| Since there are so few differences between XTM 1.0 and XTM 1.1, I
| wonder if the rationale or explanation for each of the changes
| could either be spelled out (just briefly) following each bullet
| (since Annex E is informative it's not horribly important what
| exactly the text says, just a help for those interested in using
| 1.1), or if it's not deemed appropriate to have it in the standard
| itself, a pointer to the rationale? This would be beneficial infor-
| mation to those upgrading/updating their software and Topic Maps.

That's a valid point. I wonder what other people think. Should we do
this in the annex?
 
| And if not in the document at all, perhaps just answer on the list:
| 
|  >  The instanceOf element is now allowed inside the baseName element.
| 
| What does it mean? This one is the most confusing to me, in terms
| of what it means to the processing model, the Topic Maps "conceptual"
| model, etc.

Look at the data model and you'll see that topic names now have a
type. For more background, see

<URL: http://www.infoloom.com/pipermail/topicmapmail/2004q1/005689.html >

(You probably need to read carefully, since this explains the issue
from a different angle.)
 
* Lars Marius Garshol
|
| The resourceRef element is now allowed inside the parameters,
| instanceOf, and roleSpec elements.
 
* Murray Altheim
|
| What do each of these mean?

I'm not sure what you want to know, really. The XTM 1.1 specification
explains what to do when you find the element in those places, if
that's what you mean.
 
* Lars Marius Garshol
|
| The topicMap element now has a new version attribute.
 
* Murray Altheim
|
| (This one seems pretty obvious.)

Yeah. :-)

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >