W3C

XLink Candidate Recommendation Disposition of Comments

$Revision: 1.6 $

This version:
http://www.w3.org/XML/2000/10/xlink-CR-comments
Editor:
Daniel Veillard (W3C) <veillard@w3.org>

Abstract

This document details the responses made by the XML Linking Working Group to issues raised during the Candidate Recommendation (beginning 3 July 2000 and ending 3 October 2000) review of XLink . Comments were provided by XML Linking Working Group members, other W3C Working Groups, and the public via the www-xml-linking-comments@w3.org (archive) mailing list.

Status

This document of the W3C's XML Linking Working Group describes the disposition of comment as of $Date: 2000/12/15 15:39:58 $ on XLink Candidate Recommendation. It may be updated, replaced or rendered obsolete by other W3C documents at any time.

For background on this work, please see the XML Activity Statement.

It is possible to consult the disposition of Last Call comments

Table of Contents

1 Introduction
2 Editorial Comments
    2.1 Spelling Errors and Other Typos
    2.2 Requests From Other Working Groups and Member Companies
    2.3 Technical Errors or Suggestions
    2.4 Additional Features


1 Introduction

This document describes the disposition of comments in relation to the XLink Candidate Recommendation. The comments have been categorized: editorial comments (consisting of spelling and grammatical errors), requests from other Working Groups and Member Companies, technical errors or suggestions in the current specification, and finally, additions to the feature set of Xlink. Each issue is described by the name and contact information of the commentator, a description of the issue, and either the resolution or the reason that the issue was not resolved.

Issues that were based on expanding definitions, clarifying material, or otherwise based on subjective interpretation of the specification's quality have been omitted from this document for the sake of brevity. It may be assumed that such issues were taken into account by the Working Group, and that it is the Working Group's opinion that the current text is sufficient.

Finally, basic issues in terms of spelling and grammatical errors that have been resolved since being raised are not included in this document, for the sake of brevity.

2 Editorial Comments

2.1 Spelling Errors and Other Typos

Issue (editorial-olson):

From David Olson :

It seems that between

"A simple case of a hyperlink is an HTML A element, which has these characteristics:"

and

"This set of characteristics is powerful, but the model that underlies them limits the range of possible hyperlink functionality."

there was intended to be some list of characteristics of the HTMl a tag.

Resolution (Member Only): Accepted, editors were asked to fix it.

This issue relates to XL99 in the Issues List.

Issue (editorial-lesch):

From Susan Lesch raised a number of editorial issues:

  • After clause 1 par. 3, "these characteristics:", the characteristics seem to be missing.
  • In 2.3 par. 2, "the the" -> "then the"
  • acronyms in gifs
  • gif background
  • acronym definition in 5.1
  • using "crosshatch" and "percent sign" in 5.4

Resolution (Member Only): Accepted, editors were asked to fix those.

This issue relates to XL100 in the Issues List.

Issue (editorial-olson2):

David Olson raised an error in an example:

In Section 5.2, there is some sample XML to show how the functionality of a smiple link could be approximated by the use of an extended link. The empty content tag for the locator element is closed up too soon because it does not contain the xlink:title="..." attribute.

Resolution (Member Only): Accepted, editors were asked to fix it.

This issue relates to XL102 in the Issues List.

Issue (editorial-duerst):

Martin Dürst by way of Jonathan Marsh asked to use 'number sign' instead of 'crosshatch':

Martin wrote:

There is a very minor I18N comment to change 'crosshatch' to 'number sign' (the official name of #).

Per the WG resolution to accept this comment, I have changed this in XML Base. I stole the wording directly from XLink and XPointer, so I assume they should to be changed before PR as well.

Resolution (Member Only): Accepted, editors were asked to fix this point.

This issue relates to XL103 in the Issues List.

Issue (editorial-lainevool):

Toivo Lainevool raised the following point:

Section 5.5 of the XLink spec states: "The role and title attributes may be used on extended-, simple-, locator-, and resource-type elements. The arcrole and title attributes may be used on arc-type elements." This misses the fact that the simple-type elements may also have an arcrole attribute.

Resolution (Member Only): Accepted, editors were asked to fix the wording.

This issue relates to XL107 in the Issues List.

Issue (editorial-duerst):

Martin Dürst asked Eve Maler to add a reference to RFC 2732:

At 06:31 PM 10/20/00 +0900, Martin J. Duerst wrote: Eve - I just found that XML SE includes RFC 2732, but XLink CR doesn't. If that's not already on your list, please add it. Can you also check XPointer on this point?

Resolution (Member Only): Accepted, editors were asked to add the reference.

This issue relates to XL108 in the Issues List.

Issue (editorial-ferris):

Chistopher Ferris asked Eve Maler to clarify the following:

The attributes that describe the meaning of resources within the context of a link are role, arcrole, and title. The role and title attributes may be used on extended-, simple-, locator-, and resource-type elements. The arcrole and title attributes may be used on arc-type elements.

Resolution (Member Only): Accepted, editors were asked to fix the specification.

This issue relates to XL109 in the Issues List.

Issue (editorial-obendorf):

Hartmut Obendorf asked to clarify the use of "tooltip" elements:

In section 5.1 in the example you define a "tooltip" element. This is not used again. What's the point?

Resolution (Member Only): Accepted, editors were asked to add an example to section 5.2.7, using "tooltip" as an example.

This issue relates to XL113 in the Issues List.

Issue (editorial-obendorf2):

Hartmut Obendorf asked to clarify the use of origin on simple links:

In the same section [5.2] you state the following as a "missing feature":

  • associating a title withe the single hardwired arc
  • associating a role or title with the link as a whole

I understand the first as follows: The title attribute of the simple link corresponds to the title attribute of the external locator. Maybe this should be made a little more explicit.

Resolution (Member Only): Accepted, editors were asked to explain that the role and title attributes on simple-type elements refer to the ending resource.

This issue relates to XL114 in the Issues List.

2.2 Requests From Other Working Groups and Member Companies

Issue (presentation-context):

Eve L. Maler on behalf of the XSL/XML Linking Task Force, raised the issue of presenting an issue in a larger context:

The Linking WG has occasionally discussed (without resolution) the problem 
of controlling the presentation of an ending resource such that some larger 
scope surrounding it can be displayed along with it, to provide context for 
understanding the resource.  The task force came up with two new concepts 
to describe how to achieve this control: Processing Context and 
Presentation Context.[3]  We were able to interpret the current XLink state 
of the art as "defaults" for "settings" of these two contexts, but it would 
be ideal to offer link authors real control over them.

We ask the WG to consider, in a future version of XLink, adding link 
metadata that will let link authors specify their desired values for 
Processing and Presentation Context as necessary.

[3] http://www.w3.org/XML/Group/2000/08/NOTE-xml-link-style.html#sec-link-traversal-concepts

Resolution (Member Only): Postponed, adding this at CR is not reasonable and it won't be part of XLink 1.0 feature set. However this will definitely be added as the Task Force suggested to the list of feature to add in the following revision.

This issue relates to XL95 in the Issues List.

Issue (resource-stylesheet):

Eve L. Maler on behalf of the XSL/XML Linking Task Force, suggested adding a mechanism to specify the staylesheet to use for a link resource:

There is a question about what stylesheet to use to present an ending 
resource to a user.[4]  There are some reasonable defaults that a processor 
to take advantage of; for example, the embedded material may come from an 
XML document that has a suitable stylesheet PI in it.  However, in the case 
of embedding, a different default may suit.  In any case, it would be 
useful to provide a way for link authors to override this and choose their 
own stylesheet.

We ask the WG to consider, in a future version of XLink, adding link 
metadata that will let link authors specify their desired stylesheets for 
presentation of ending resources.

[4] http://www.w3.org/XML/Group/2000/08/NOTE-xml-link-style.html#sec-link-traversal-concepts

Resolution (Member Only): Postponed, adding this at CR is not reasonable and it won't be part of XLink 1.0 feature set. However this will definitely be added as the Task Force suggested to the list of feature to add in the following revision.

This issue relates to XL96 in the Issues List.

Issue (multiple-load-replace):

Eve L. Maler on behalf of the XSL/XML Linking Task Force, raised the issue of processing concurrent load/replace links:

Currently, the XLink specification says that the first occurrence (in document order) of such a link is the one that should be processed, and provides other guidelines as well.[5] In the specific case of XSLT, source document order is not necessarily used for processing of that document; it is under the stylesheet author's control. And in the general case, source document order cannot be guaranteed to be used by every styling technology. In addition, an onLoad/replace starting resource may be transformed in such a fashion that it disappears from the displayed output. Therefore, we suggest[6] that the specification be changed to recommend that the first onLoad/replace link encountered by an XLink application in the course of presentation be processed. This is naturally application-dependent, but more importantly it is also stylesheet- (and stylesheet technology-) dependent, which we think puts the control in the right hands. [5] http://www.w3.org/TR/xlink/#actuate-att [6] http://www.w3.org/XML/Group/2000/08/NOTE-xml-link-style.html#b2ab5b5b7b9 (members only)

Resolution (Member Only): Accepted, the editors were asked to change the specification to state that handling multiple onLoad/replace Links in a document is done in an application dependant way.

This issue relates to XL97 in the Issues List.

Issue (well-balanced-resource):

Eve L. Maler on behalf of the XSL/XML Linking Task Force, raised the issue of rendering ending resources made of multiple ranges or not well balanced ranges:

Currently, the XLink specification says that ending resources that consist of other than a single node should be presented as a "unified concatenation" of all the content in the location set.[7] We believe that this description is underspecified. There are two main cases of arbitrary location sets that need special consideration: "non-well-balanced" ranges and discontiguous series of ending resources. Concatention seems to apply to treatment of the latter case; however, we suspect that something like "aggregation" would be a more useful concept than true concatenation. In addition, aggregation is only one of a variety of possibly useful presentations (for example, providing a menu that allows for easy navigation to each location, presenting an entire document but putting the individual locations into reverse video and positioning the document view at the first location, and so on).[8] Therefore, we recommend that the specification be changed to allow for such a variety of presentations, possibly only requiring that if some ending resources are presented, then all must be made accessible to the user (that is, none should be deliberately suppressed).

Resolution (Member Only): Accepted, the editors were asked to change the specification to state that rendering ending resources made of multiple ranges or not well balanced ranges is done in an application dependant way, and remove the word "concatenation".

This issue relates to XL98 in the Issues List.

2.3 Technical Errors or Suggestions

Issue (starting-resources-handling):

From James Clark asked some clarification on the treatment of starting resources :

Why are multiple nodes in a starting resource handled in a completely
non-orthogonal way from multiple nodes in an ending resource?

He further explained:

The parts of my message
covered by XL93 were about starting resources, but XL98 is about ending
resources.  I think the decision in XL98 should be generalized to say
that the treatment of multiple node starting resources is application
dependent as is the treatment of multiple node ending resources.

@@ Resolution: Accepted, the editors are requested to state that the presentation context of the starting resources is application dependant. This will also unify the handling of source and ending resource.

This issue relates to XL93 in the Issues List.

Issue (ending-resources-presentation):

From James Clark asked some clarification about presentation of ending-resources :

In general, I was unable to understand from the description of the show       
attribute what the intended behaviour was when the ending resource was a      
fragment of a complete document.  Should it extract the fragment and          
display just that or should it display a window on the complete document      
with the document scrolled so that the start of the fragment is in the
window?

He further explained:

My point in XL94 was that I
couldn't understand what the spec requires.  For example, for "embed"
the spec says "An application traversing to the ending resource should
load it in place of the starting resource".  Suppose I have an XPointer
that points to a paragraph within a document.  What does it mean to
"load" that paragraph in place of the starting resource? It is not at
all clear from the spec.  Specifically, the distinction between XInclude
embedding and XLink embedding which is very helpfully explained in the
Linking and Style document doesn't come through.  Merely saying that
"embedding affects only the presentation of the relevant resources; it
does not dictate permanent transformation of the starting resource"
isn't enough: that doesn't effectively exclude the XInclude approach. 
>From the decision on XL95, I gather that the intent is that the
presentation context is application-dependent.  If you don't say this
explicitly, people won't figure this out.  For example, the difference
between "replace" and "embed" is naturally understood as saying
something about the difference in presentational context of the ending
resource.  If it's really just constraining how traversal affects the
presentation of the starting resource, then that needs to be spelled
out.

@@ Resolution: Accepted, the editors are requested to state that the presentation context of an embedded resource is application dependant.

This issue relates to XL94 in the Issues List.

Issue (relative-URI):

From Eric van der Vlist raised the following issue for the URI Reference used by semantic attributes:

The value of the role or arcrole attribute must be a URI reference as defined in [IETF RFC 2396]. The URI reference identifies some resource that describes the intended property. When no value is supplied, no particular role value is to be inferred. Disallowed URI reference characters in these attribute values must be specially encoded as described in 5.4 Locator Attribute (href).

Questions such as :

  • are relative references allowed ?
  • how should they be processed ?
  • when are 2 semantic attributes equal ?
  • can be left to the application designers, but aren't we risking, to some extent, to see the same debates than for namespaces URIs ?

Resolution (Member Only): Accepted in some ways. The Working group draw some analogy with the naming convention used for namespaces, and decided to adopt the same attitude and forbid relative URI references for role and arcrole values at least for version 1.0 of XLink. Microsoft and Jamcracker opposed the change and published a minority opinion.

This issue relates to XL101 in the Issues List.

Issue (remove-arcrole):

From Eliotte Rusty Arold suggested to remove arcrole and fold it into role:

.... I propose making XLink simpler by deleting arcrole and allowing role attributes on arc elements. A suggestion as to what the role of an arc element should be can still be provided, but I see no justification for two separate attributes here.

Resolution (Member Only): Rejected, while this looks an interesting simplification, simple links can't have both an arc role and a role for their remote resource if we don't have two separate attribute names.

This issue relates to XL104 in the Issues List.

Issue (remove-title):

From Eliotte Rusty Arold suggested to remove title support:

I'm really not sure they're necessary or useful in practice, and I'd like to propose simplifying XLink by deleting all reference to title type attributes. ....

Resolution (Member Only): Rejected, the Working Group looked at the possibility of removing title attributes, title elements, or both. There was clear support from the I18N Group for having title elements support in XLink. They are not mandatory, but it seems their support is needed, so the Working Group decided to keep the status quo.

This issue relates to XL105 in the Issues List.

Issue (change-resource-name):

From Eliotte Rusty Arold suggested to rename the type of the local resource from resource to something else such as "local":

.... What I'm proposing is to rename the type of the local resource from
resource to something else such as "local". The reason is that a
resource element doesn't really represent all kinds of resources, just
local ones. I'm not wedded to the name "local". I just don't want it to
be "resource".

Another possibility is to rename the resource type to local and the
locator type to remote, though I suppose that might be a little
confusing when the locator locates an element in the same document. Or
we could rename locator "uri" and resource "here". That more clearly   
indicates what's expected in the attribute value.

Resolution (Member Only): Rejected, the Working Group looked at various name change (change "resource" to "local", change "resource" to "local" and "locator" to "remote", change "resource" to "here" and "locator" to "uri", ...) but this ended up being considered a taste issue, and there was no consensus to change the syntax in that direction at this point.

This issue relates to XL106 in the Issues List.

Issue (container-location):

From Matthew Wilson pointing at "container location" vs. "container nodes" wording:

In 5.4.3, in the definition of the range-inside function, there is:

"If x is not a range location, then x is used as the container location of 
the start and end points of the range location to be added; the index of 
the start point of the range is zero; if the end point is a character point 
then its index is the length of the string-value of x, and otherwise is the 
number of location children of x."

This refers to the "container location" of points; however points are 
defined in terms of "container nodes", and the term "container location" is 
not used elsewhere. This seems odd. (Specifically, what is added to the 
result location-set when the input location set contains a point? 
Presumably, a collapsed range containing the point, but can this be deduced 
from the spec?)

Resolution (Member Only): Accepted, Change "container location" to "container node" in 5.4.3.

This issue relates to XL110 in the Issues List.

Issue (multiple-arcs):

From Hartmut Obendorf suggested to give links with multiple arcs a specific name:

In section 2.3 inline, outline and third-party links are defined as linky
with only one arc. Links with more than one arc (let's call them complex 
links here) aren't given a name. This doesn't make sense to me as I thought
one of the great things about XLink was exactly that you wouldn't have to
live with a single arc per link. Even a two-way link has two arcs and 
doesn't have a designated name (like 'complex link') according to the 
standard.

I would argue that _most_ XLinks will use more than one arc and therefore
most XLinks are not taken care of by this definition.

Resolution (Member Only): Rejected, the Working Group could not find a real need for just adding a new name for this construct.

This issue relates to XL112 in the Issues List.

2.4 Additional Features

Issue (XLink-DTD):

From Murray Altheim suggested adding an XLink DTD :

I guess I would want an XLink DTD that stated "these are the defined structures and meanings associated with XLink 1.0, if you get validation errors they mean that the linking constructs you've used aren't defined by the XLink specification but may be valid in your application."

It's just hard sometimes to know what is and what isn't actually an XLink-defined structure, and having only prose text and examples to go on is somewhat difficult.

Resolution: Accepted, such a DTD has been added in the new draft.

This issue relates to XL111 in the Issues List.