ISO/IEC JTC 1/SC34 N0399, 2003-04-03
|
Title: |
XTM: Proposed issue resolutions |
|
Source: |
Lars Marius Garshol, Graham Moore, JTC1/SC34 |
|
Project: |
ISO 13250 |
|
Project editor: |
Steven R. Newcomb, Michel Biezunski, Martin Bryan |
|
Status: |
Proposed issue resolution |
|
Action: |
For review and comment |
|
Date: |
2003-04-03 |
|
Summary: |
|
|
Distribution: |
SC34 and Liaisons |
|
Refer to: |
|
|
Supercedes: |
|
|
Reply to: |
Dr. James David Mason |
This document sets forth the authors' proposed resolutions to all currently open issues in the Standard Application Model, together with the rationale for those resolutions. Interested parties are requested to offer their comments on these.
We propose that only bare names should be allowed, since full XPointer support requires implementations to build a complete document tree, which is too onerous a requirement.
We consider that since XLink forbids spaces (and other illegal characters) from appearing in the xlink:href attribute, XTM must follow suit and also forbid them.
We also consider that errors in XTM documents should cause the XTM document to be rejected and not loaded by the implementation.
We consider that since resourceRef is allowed in scope and mergeMap it must also be allowed in parameters. We also consider that although its use in instanceOf and roleSpec is somewhat suspect, we cannot be certain that there will never be a case where it is in fact correct. We therefore recommend that resourceRef should be allowed in instanceOf and roleSpec as well.
We consider that although it may be confusing to allow IDs on element types which cannot be reified it is not inconceivable that these IDs may have legitimate uses, and in any case removing them would not be backwards compatible. We therefore recommend that they remain.
We consider that the addition of typed names, as well as the changes regarding resourceRef justify the version number 1.1, which is probably also reasonable from a political point of view.
We propose that the xlink:href attribute be declared to be of type anyURI, as this clearly documents what the attribute may contain, and there are no negative side-effects.
We propose that this be left for later versions of XTM, if it is to be included at all.
We propose that this be left out, as it is only useful in a few situations where XTM documents are authored by hand, which they very rarely will be, and for which they are in any case eminently unsuited.
We consider that since the SAM allows multiple [subject addresses] on topic items, the content model of subjectIdentity should be relaxed to (resourceRef | subjectIndicatorRef | topicRef)*. The rationale is that the syntax has to follow the model, and the change is in any case very slight as well as backwards compatible.
We consider that this change is too intrusive to justify the slight gain in conciseness, although we do think that later versions might want to deprecate certain constructs in the syntax.
We consider that although this change would be welcome, it is too much of a change at the current stage. We would recommend that this change be made in a future version of XTM.
We consider that this should not be considered an error. Existing practice is to allow this, and a change would thus not be backwards compatible. Processors should be allowed to issue a warning, however.
We consider that this should be required, since topicRef elements are required to point to information resources following the XTM syntax, which again means that any topic element referred to must be contained in a topicMap element.
We consider that this should be an error, since the mergeMap reference is ambiguous in this case.
We consider that namespace processing should be required. To have an XTM namespace without using it begs the question of why there is a namespace there at all. XTM is also designed to be embedded in other syntaxes and for this namespaces really are required. The conclusion is that namespace processing should always be required.
Given that we require namespace processing changing the namespace URI will cause XTM 1.0 and XTM 1.1 element type names to be different (as they will have different namespace URIs), and so it seems clear that we cannot do this.
We consider that it is necessary for implementations to be able to detect immediately upon encountering the topicMap element which XTM version they are reading, however. To achieve this we propose to add a required version attribute to the topicMap element.
If namespace processing is to be required the DTD cannot be the normative schema, since XTM documents using namespace prefixes would then be invalid according to the DTD. Instead, we propose that the RELAX-NG schema be made the normative schema. This because it has a compact syntax that can be used throughout the specification, because it is (or will be) an ISO standard, and because this allows us to handle the problems with fixed attributes.
Not requiring DTD compliance means that XTM documents can do the namespace declarations any way they want, so long as the namespace URIs are actually declared and used correctly. A consequence of this is that relying on the DTD to infer them is not recommended, but still possible. This should be spelled out in a note.
The XLink type attribute is a different case since without it the XLink elements are not valid according to the XLink specification. Our feeling is that this attribute should be made optional, but that if given it should be required to have the value 'simple'. This because otherwise XTM documents that rely on using the DTD to have these attributes added will not be valid when read by processors which do not read the external DTD subset.
We consider that unknown elements inside the topicMap element should be considered errors, since this allows us to have a strict schema for XTM. The version attribute ensures that XTM 1.1 topic maps can be identified and that future software will be able to detect which version they are reading.
We consider that although refering to elements which are not topic elements is an error detecting this can be very expensive when reading large XTM documents. For this reason we do not want to enforce detection of this error in cases where it does not cause a topic item to be merged with information items which are not topic items.
We consider that the only correct solution here is to make URI references of the forms "" and "#foo" relative to the document URI, rather than the base URI. This means that if the xml:base attribute is set it will not affect the absolute URIs created from such URI references.
This is the behaviour required by RFC 2396, and it is also necessary because otherwise internal topicRef references (as well as references from the outside pointing in) would stop working as the references would not match the source locators generated by the topic elements.