XLink Disposition of Comments

2.1.3. Multiple roles

Source: Philippe Le Hegaret , http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0070.html

Has having multiples roles on the role attribute (and from/to attributes) been considered by the linking WG ?

Resolution: Dropped, we considered the issue but decided not to add this in the 1.0 version of XLink, Philippe agreed.

2.1.5. Organization: conformance and terminology

Source: Dan Connolly , http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0068.html

Dan suggested a number of editorial changes:

• Move section 4 on conformance before section 3
• Review of may/must/should terminology
• Reorganizing the definitions
• Reference to RFC2396

2.1.6. Definition of "URI reference"

Source: Martin J. Dürst, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0080.html

The definition of "URI reference" should point normatively to RFC 2396, and also the update of RFC2396 for IPV6, the hyphen should be dropped.

Resolution (members only): Accepted, the editors changed the specification accordingly.

2.1.7. Examples are confusing

Source: Martin J. Dürst, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0080.html
HTML WG , http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0006.html

In 2.3, Attribute defaulting is introduced. However, because the DTD fragments with the defaults appear only some pages later, the rest of section 2, and the first part of section 3, is rather difficult to read or understand. Reorganizing the spec on a large scale would solve that problem. In 2.3, at least one example with all the relevant DTD fragments should be given.

Resolution (members only): Accepted, there is now a complete example in 5.1, and the examples have been reorganized in order to clarify them. The problem of multiple course children has been fixed.

2.1.8. Violation of 'mandatory conditions' behaviour

Source: Henry S. Thompson, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0067.html

Although 'must' etc. are used as per IETF whatever, no discussion of error behaviour is provided, i.e. in section 4.3 point 2, nothing is said as to what "observing the mandatory conditions" means

Resolution (members only): Rejected, Henry is asking what applications should do when they don't "observe the mandatory conditions". The specification states what an application must do to be considered conforming, so there is no prescribed behavior when an application does not conform. If he asks what it means to not meet a "must" in XLink specification, this means the link won't work.

2.1.9. Limit of the 'application' definition

Source: Henry S. Thompson, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0067.html

The definition of 'application' in the (presumably normative) terminology section (1.3) implies that a conformant processor of _any_ document with linked-from resources must recognise that fact. This is clearly to strong a requirement in the case where the document in question contains no linkset information.

Resolution (members only): Accepted, the definition in section 3.3 has been changed to avoid that problem

2.1.10. Definition of 'element'

Source: Henry S. Thompson, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0067.html

I saw nowhere which made clear whether the term 'element' throughout, and particularly in section 4.2, refers to an Element Information Item as defined in the Infoset PWD, or to a character sequence in an otherwise non-well-formed non-XML document.

Resolution (members only): Accepted, the definition in section 3.3 has been changed to make reference to XML Information Set, and the fact that the XML document is well formed.

2.1.11. Add a robot PI

Source: Walter Underwood, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0087.html

Robots are an important class of link-aware applications. Document authors need to be able to give hints to robots about whether the links in a document should be followed.

Resolution (members only): Rejected, This a separate mechanism. This should however be sent to W3C as a Note and companies from WG members are ready to support this submission to W3C. The author was notified but did not retract.

2.2.4. XML Schemas definition for XLink

Source: The XML Schemas WG , http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0081.html
Henry S. Thompson, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0067.html

We were requested to provide an XML Schemas definition for XLink constructs.

Resolution (members only): Rejected for the moment. XML Schemas is not likely to go to REC before XLink, so providing a normative XLink schemas definition would be a problem. However some members of the Working Group have provided a first schemas for XLink constructs (members only). We expect this to be developed more during Candidate Recommendation phase, hoping that support of attribute remapping will be possible.

2.2.5. Not meeting requirement of handling existing markup

Source: The HTML WG http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0073.html,
the SYMM WG http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0082.html
Lloyd Rutledge clarification http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0045.html

The HTML WG philosophical report concludes with:

Xlink does not meet the basic requirements it set itself, nor of its 'customers', and as such is insufficient for the needs of the future web. Any linking proposal that requires documents to be changed in order to use linking is not suitable.

The SYMM WG argues:

The original requirements of XLink, as described in the requirements document, include representing the HTML hyperlinks conveyed by the HREF and SRC attributes, and enabling any XML document to have its hyperlink semantics recognized, regardless of its syntax. The XML Linking working group has since made the decision not to meet these requirements.

Resolution (members only): Rejected, the XML Linking Working Group decided not to add support for attributes not attached to the XLink namespace. The XML Linking Group hope that XML Schemas will allow attribute remapping, or at least provide a way to attach href attributes without namespace to the XLink namespace (c.f. Henry S. Thomson's mail). The Working Group provided a more elaborate answer (member only) to the proposal submitted by the HTML Working Group.

2.2.6. Remove external linksets

Source: Arbortext , http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0044.html
Academia Sinica , http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0047.html

Given that out-of-band methods are ideal, some of us feel that providing an in-band method is inappropriate, and we would prefer not to have any syntactic specification for external linksets in the XLink specification.

Paul Grosso suggested to use a packaging mechanism to associate linkbases. Rick JELLIFFE suggested that in the absence of a packaging mechanism the working group add a paragraph explaining that the role attribute can already be used for a kind of packaging mechanism.

Resolution (members only): Rejected the Working Group decided to keep the external link set construct, useful to advertize link bases in decentalized annotation systems. The syntax used to construct it has been modified to match more closely other types of links. Arbortext message represent a minority opinion from a working group member.

2.2.7. External linkset can be declared anywhere in the document

Source: DOM WG, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0084.html
Henry S. Thompson, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0067.html

Lauren wrote

3.1.5 - it appears the entire (potentially large) document must be searched to resolve XLinks (although DTD declarations could help). This could be expensive in a large document, no matter how efficiently implemented. We suggest some guidance to users for large documents, such as encouragement to declare XLink as early in the document as possible. This applies to both external linksets and out-of-line links.

Henry wrote

In 3.1.5, I'm not sure that requiring sensitivity to role=xlink:external-linkset _anywhere_ in a document is coherent -- at the very least it seriously disadvantages streaming processors.

Resolution (members only): Accepted, but external linksets are normal XLinks. XLink conforming applications must handle extended links anywhere in the document, including the case of external linksets. DOM suggestion is really based on a particular type of XLink implementation and not due to a normative behaviour of XLink. However we added the following sentence to 5.1.5 Locating Linkbases: " To ease XLink processing, document creators may wish to define linkbase arcs near the beginning of a document."

2.2.8. DOM: Accessing embedded documents

Source: DOM WG, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0084.html

Lauren wrote

there is no way in the DOM currently to go from the document to the embedded document. This would be left to the XLink implementation.

Resolution (members only): Acknoledged, Currently there is no XLink specific DOM API. Until such an API get defined there won't be a way to get access to the embedded object instance.

2.2.9. HTML: Remove the title constructs

Source: HTML WG, http://lists.w3.org/Archives/Member/w3c-xml-linking-wg/2000Jun/0034.html

The description of the title attribute here is very vague, and we wonder if it should be in Xlink at all. Since such an attribute is turning up in several W3C recommendations, it seems better to be applied to XML as a whole rather than each application adding a new, slightly different, version.

Resolution (members only): Rejected, the title attribute and elements have been refined in close coordination with the I18N working group and meet their approval. The title constructs are optional to use. If another title construct gets standardized, it will be easy to use it in conjunction with XLink. In the meantime, XLink needs to provide its own title constructs.

2.3.5. HTML WG Editorial comments

Source: HTML WG, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0006.html

• Abstract: can describe the simple unidirectional hyperlinks of today's HTML
• Section 3: 'linkset' used here but not defined
• Section 3.1.1: use contained resource instead of local resource
• Section 3.4: "must be receive XML base..."

Resolution: Accepted, except for the change of "local resource" since the definitions in 2.3 define precisely the meaning of "local resource" and "remote resource". The Abstract has been changed to "...structures that describes links similar to the simple unidirectional hyperlinks...".