ISO/IEC JTC 1/SC34 N0399, 2003-04-03

 

ISO/IEC JTC 1/SC34

Information Technology

Document Description and Processing Languages

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
(ISO/IEC JTC1/SC34 Chairman)
Y-12 National Security Complex
Information Technology Services
Bldg. 9113 M.S. 8208
Oak Ridge, TN 37831-8208 U.S.A.
Telephone: +1 865 574-6973
Facsimile: +1 865 574-1896
E-mail: mailto:[email protected]
http://www.y12.doe.gov/sgml/sc34/sc34oldhome.htm

Mrs. Sara Desautels, ISO/IEC JTC 1/SC 34 Secretariat
American National Standards Institute
25 West 43rd Street
New York, NY 10036
Tel: +1 212 642-4937
Fax: +1 212 840-2298
E-mail: [email protected]

XTM: Proposed issue resolutions

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.

xtm-href-xpointer

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.

xtm-href-whitespace

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.

xtm-where-resourceref

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.

xtm-unused-ids

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.

xtm-version

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.

xtm-schema-uri

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.

xtm-xlink-actuate

We propose that this be left for later versions of XTM, if it is to be included at all.

xtm-xmlbase-everywhere

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.

xtm-subjectidentity-children

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.

xtm-variantname-deprecate

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.

xtm-parameters-deprecate

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.

xtm-topicref-notopic

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.

xtm-topicref-fragment

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.

xtm-mergemap-reference

We consider that this should be an error, since the mergeMap reference is ambiguous in this case.

xtm-namespace-support

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.

xtm-namespace-uri

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.

xtm-normative-schema

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.

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

xtm-unknown-elements

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.

xtm-topicref-notatopic

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.

xtm-same-doc-refs

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.