[XL1] Evaluate the level of HTML support and give feedback to the XHTML WG

Lloyd message reporting the problem
http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/1999Jul/0021.html

Steven Pemberton's first Note on the subject
http://www.w3.org/MarkUp/Group/1999/19990512-Xlink-for-HTML.html

Lloyd took the ACTION to work out this Liaison issue with Steve Pemberton http://lists.w3.org/Archives/Member/w3c-xml-linking-wg/1999Jul/0026.html

This is urgent since XHTML is stuck in last call until this is solved

Options:

1. Explicitly put all the HTML4 apparatus (LONGDESC, SCRIPT, FRAME, QUOTE,HEAD, and BASE) into XLink
2. Find a way to fake it so that an HTML4 <A> element with all this stuff is still a correct XLink, even if XLink doesn't actually specify these elements
3. Do nothing
4. Provide XLink constructs for defining all linking constructs requested by the working groups for XHTML, SMIL, SVG and other formats that use XLink.

Resolution:

Closed, c.f. [XL70] and [XL83]

[XL2] Evaluate SMIL requirements

SMIL Requirements for XLink/XPointer http://www.w3.org/AudioVideo/Group/Linking/requirements-19990409.html

This will affect the linking part of the SMIL v2 Working Draft

They want:

SMIL1. non-XLink attributes allowed on XLinks

Decision: Yes/No

SMIL2. add the "pause" attribute value to show=

Decision: Yes, No, or it's moot because we lose show=

SMIL3. Try to minimize the number of attributes required on the XLink constructs, even in the case where you can't default attributes

Decision: Yes/No

SMIL4. multiple locator attributes on one element

Decision: Yes/No

SMIL5. locator *attributes* and *elements* on same xlink

Decision: Yes/No

Resolution: 1/ yes 2/ no 3/ not changed 4/ no 5/ no

See [XL78]

[XL3] Evaluate SVG requirements

Chris Lilley wrote to the CG:
http://lists/Archives/Member/w3c-xml-cg/1999Jul/0092.html

-------------

I really, really do not want to drop XLink and make up our own SVG-specific linking syntax but some of the SVG WG are pressing for this and are now making concrete proposals ("just the same as HTML 4.0 - href and src") so I would like some good news to report back to them, preferably of the form "XLink was published yesterday".

To clarify, SVG is only using simple links, not compound links; and does not have a requirement to have multiple links per element. We are also using XPointer, and thus by implication (parts of) XPath. We use XLink for the following three cases:

1. Image inclusion (like HTML <IMG SRC="url">, except using XLink)
2. Hyperlinking (like HTML <A HREF="url">, except using XLink)
3. Symbol referencing, this can be internal or external, which is why we used XLink not IDREF.

---------------

One important point of the dependancy is that when SVG will go to PR it must have a stable (PR or PR ready) XLink draft to reference. This put a serious time constaint on XLink schedule.

Options:

1. Seems Ok, points 1. 2. and 3. are simple links, XPointer should be able to handle 3. addressing needs, the only problem is the time constraint

Tim Bray: Not an issue here; I think SVG is happy with us the way we are, take this point away

Resolution:

XLink fullfill SVG requirements, this was checked at the f2f in Sophia, item closed

[XL4] Type and Role should be defined as primary web objects

http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999JulSep/0003.html

Feedback from W3C staff and especially Tim BL Having URIs to describes type and roles is needed to avoid ambiguities, It's easy to find multiple meaning for our example role="essay" Using URI do disambiguate can be achieved by the way of a namespace added to the type/role or forcing type/role to be an URI.

Options:

1. keep them as-is, i.e. free form text
2. provide a namespace construct for type and role content

   2.a - use a colonized style, depending on the in-scope namespace declarations, a la XSL.

   2.b - invent some other syntax e.g. a roleNS= attribute that can go on either the linking or locator element, to hold the URI

3. make them of type URI

Resolution:

Consensus on 2.a/

This was actually extended later c.f. [XL75]

[XL5] Relationship with RDF

It's in our requirements
A 10: XLink should be expressable in terms of RDF.

A simple example on how XLink constructs can be mapped onto RDF assertion is sufficient to fullfill this requirement.

This can be kept as a internal WG document, promoted a Note or added as an appendix to Xlink WD

Options:

1. We invest some time and work in showing how Xlink is expressible in RDF
2. We agree that it is expressible and close the issue

Resolution:

The Working Group will provide a mapping of XLink constructs using RDF. This will be non-normative and may be published as a separate NOTE. c.g. mails crossposted to rdf-interest list and IG.

[XL6] Extending/Consolidating Extended Link groups in the draft

[discussed but still open]

This is the part which was rewritten last, and it need some refinement, multiple complete example wouldn't hurt either this is new to most web authors.

http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/1999Jul/0107.html

Option:

1. Direct the editors to refine the XLG section
2. Leave it as it is
3. Drop the section

Resolution:

Consensus on 1/ with a subgroup refining the description

[XL9] show="parse" underspecified

Is show="parse" adequate to indicate an inclusion in an interoperable way? What are the infoset ramifications of such an inclusion? What is the interaction between show="parse" and the actuate attribute values? Should inclusion processing be left to the application, or should we define the processing model for inclusion? Should the syntax more clearly differentiate inclusion from other types of links?

Options:

1. Junk show="parse" with no replacement.
2. Form a subgroup to synthesize the various include proposals into a minimal inclusion which describes both syntax, processing model, and the relationship/impact on the infoset. I imagine such a proposal would result in the subgroup preparing the text of a new section in the XLink WD, and may result also in suggestions for changes in other parts of the draft.

Resolution:

consensus on show="parse" to be dropped

[XL11] Leveraging refinement

Should we define a "base class" of link from which other links can be derived? Do we need the global-attribute variation of XLink? Can we leverage a datatype mechanism such as that expected from the Schema WG for link recognition? Currently addresses (URI Reference) can be recognized by datatype, why can't "handles"? Can an extended link be derived from a simple link?

Options for leveraging a datatype mechansim:

1. Describe the relationship of the URI Reference data type and the XLink data type, and rely on a refinement mechanism for retrofitting HTML and other grammars.
2. Define a different mechanism for retrofitting HTML and other grammars.
3. Don't support retrofitting of HTML and other grammars (in other words, do nothing).
4. Do nothing. Everything is fine as it is.

Resolution:

4/ deferred to Schema availability

Options for the global attribute variation:

1. Get rid of the global attribute syntax.
2. Note that the global attribute variation is an interrim measure to allow users to define element names in anticipation of a refinement mechanism.
3. Do nothing. Everything is fine as it is.

Resolution:

3/ done

Options for the base link class:

1. Define a base link class, and show how this can be refined into an extended link.
2. Define a base link class, and get rid of extended links, as we can't describe how they can be refined into extended links.
3. Do nothing. Everything is fine as it is.

Resolution:

3/ done

[XL14] What is the final XLink namespace URI

assuming we become a REC

Possible decisions:

1. http://www.w3.org/XML/XLink
2. Include a datestamp or version number

Resolution:

- consensus on http://www.w3.org/namespace/xlink/1999/ and http://www.w3.org/namespace/xpointer/1999/

Note that this is suject to final approval from W3C Web team who manages the URL space

Update:

This has been changed upon W3C webmaster request to:

http://www.w3.org/1999/xlink

[XL17] TITLE attribute impoverishment

The title is supposed to convey human-readable information. How do we deal with the fact that humans don't all speak the same language, or the case where the human-readable information isn't textual?

Possible decisions:

1. ignore this question
2. install a level of indirection (reserved roles?) for title

Resolution:

[XL18] ELG steps

Should there be a default, and what should it be?

Possible decisions:

1. no default
2. default=1
3. default=2

Resolution:

No more step attribute and removing the non-indirecting version of extended link, and we are adding a note that user-agent may constraint the steps on the user's behalf.

[XL20] Evaluate the WAI requirements

The initial issues raisedby the WAI Working Group in April:

http://www.w3.org/WAI/PF/Group/xlink.htm

The latest mail sent by Daniel Dardailler in June:

http://lists.w3.org/Archives/Member/w3c-xml-linking-wg/1999Jun/0045.html

They want

[WAI1] If XLink is supposed to be used in all XHTML contexts where URI appears, special constructs for accessibility must be preserved like SRC and LONGDESC on IMG.

Decision: Closed by WAI

[WAI2] Expressivity of the ROLE attribute: Xlink should not result in a loss of functionality compated to HTML4 specific attributes, especially the MEDIA attribute

Decision: Closed by WAI

[WAI3] The need to develop an extensible repertoire of ROLE types, with common semantics, like PREV NEXT, TOC, etc. on HTML LINKs

Decision: Closed by WAI

[WAI4] Structured titles and the ability to include markup in the title

Decision: already in XLink own issue list.

[WAI5] link behaviour must be described in the XLink specification, in an appropriately device/medium-independent manner.

Decision: It is expected that we have removed any device/media dependant parts, except maybe in examples. We should continue to check against that.

[WAI6] Link activation mechanisms: lack of an equivalent in XLink to the HTML 4.0 ACCESSKEY attribute.

Decision: Closed by WAI

[WAI7] the XLink specification provides no counterpart to the HTML 4.0 attributes which permit script events to be attached to links.

Decision: Closed by WAI

[WAI8] Some combinations of Show and Actuate introduce new ways of implementing existing functionality, like OBJECT (embed, auto) or HTTP Refresh/Redirect. It should be clear what is the overall W3C strategy in all cases.

Decision: Closed, one need more clarification. Showing how XLink could be used in an accessible way. WAI should provide guidelines on how to use those constructs in an accessible way.

[WAI9] Adding in the conformance section: user configuration should have highter priority than default behaviour.

Decision: Look at what SVG has done.

Side note: the support for specific HTML constructs just piles up in various requirements. Wouldn't allowing the HTML attributes on XLink element, but associated to an HTML namespace solve the problem. If the XML processor happen to understand the HTML semantic, it will be able to make use of it, if not, well. At least it allows to borrow extra pieces, while avoiding to reference external specifications (HTMLx/XHTML) by copy inside XLink.

[XL21] Dealing with relative URIs in XLinks

XLinks specify resources using URIs. It would be best if relative URIs were allowed as well as absolute ones. Currently the XLink specification does not provide the equivalent of the HTML BASE element.

Section 5.1 of RFC 2396[1] says:

The term "relative URI" implies that there exists some absolute "base URI" against which the relative reference is applied. Indeed, the base URI is necessary to define the semantics of any relative URI reference; without it, a relative reference is meaningless. In order for relative URI to be usable within a document, the base URI of that document must be known to the parser.

The base URI of a document can be established in one of four ways, listed below in order of precedence. [...]

First in the order of precedence is:

5.1.1. Base URI within Document Content

Within certain document media types, the base URI of the document can be embedded within the content itself such that it can be readily obtained by a parser. [...]

Then other methods are given (Base URI from encapsulating entity, from the retrieval URI, and finally, provided as an application default).

Options:

1. Do nothing - allow the three other methods to provide the base URI for resolving relative URIs.
2. Define an xlink:base attribute that takes a URI to use as the base for resolving relative URIs. In the absence of such an element, the other three methods are used.

   2.1)What is the scope of a xlink:base attribute?

   1. Throughout the scope of its element, unless overridden by another xlink:base on a descendent element. (ala xml:lang, xmlns:*, etc.)
   2. something else
3. Something else - adopt SNIP wholesale?

Resolution:

Ron to update the proposal, send it to the CG, and try to get it as a more general framework. The XLink group would propose a base element with a propagation mechanism similar to the xml:lang one.

Update: XML Base is now a separate specification handled in parallel to XLink

[XL22] Implicit arcs

Description @@

Choices

1. remove all mention of implicit arcs, remove prose
2. keep as is

Resolution:

Consensus on removing all mention of implicit arcs

[XL23] hub-view role

Description @@

Resolution:

@@ Dropped by lack of a clear description of the problem

[XL24] HTML Support Requirement

Should we change this text from 'must' to 'should', considering that we don't explicitly support HTML 4.0 linking constructs?

Options for resolving the issue:

1. Leave it.
2. Change the description to 'should'.
3. Ben Trafford suggests: Change the text to read: XLink must strive to support common HTML linking mechanisms.

Resolution:

Leave it

Check the related issues [XL70] and [XL83]

[XL25] Simple Link Recursion

Should simple links exclude xlinks as conforming content? The XHTML PR is an example of a simple link vocabulary that prohibits multi-leveled simple link content in the A element, see the XHTML draft.

Proposal: The editors propose that a simple link conformance test be stated that a simple link can not contain any xlink linking elements, specifically simple and extended links. Ben Trafford notes that this might exclude some applications, where the actuation is automatic, allowing for the reification of multiple levels of links. However, perhaps that level of functionality is best left out of simple links?

Options for resolving the issue:

1. Do nothing.
2. Adopt the editor's proposal.
3. Others...?

Resolution:

Allow nested links, add non-normative examples to make sure implementors don't miss the point.

Update: there is currently prose but no example @@

[XL26] Extended Link Validation

We can't validate XLinks with a mandatory locator and optional arcs + locators. What does the DTD look like?

Options for resolving the issue:

1. Write a DTD that resolves this ambiguity. Ben Trafford has been working on it, without success as yet.
2. Change the defintion of mandatory and optional arcs and locators.
3. Others...?

Resolution:

This is a limitation of current DTD syntax, can't ensure role usage. Problem in showing XLink DTD. arc*, loc, (arc | loc)*

Eve to try to build that DTD, WG trust her on deciding on the quality of that DtD

Update:

Check Schemas support [XL79]

[XL27] Conformance Tests

The set of conformance tests appears incomplete. Only 2 conformance tests are listed, along with an issue on simple link conformance.

Options for resolving the issue:

1. The XML Linking IG should be polled for further conformance tests.
2. The editors should write a series of conformance tests.
3. Others...?

Resolution:

Having a complete set described onto a single section seems hard, editors will try to keep a list (if needed by reference).

Update:

Will probably be needed to exit CR anyway (separately).

[XL28] OBJECT fallback.

The mapping of HTML to XLink raises some questions. What about the HTML OBJECT element which has semantics that includes going through its descendants and determining which one(s) are effective? We can support the semantics now, but this raises the issue of addressing nested linking elements.

Options for resolving the issue:

1. Do nothing.
2. The editors could write some rules for the processing of nested links.
3. Others...?

Resolution:

Dropped.

[XL29] Resource Media Specification.

It's important that XLink does not result in a loss of functionality compared to HTML4 specific attributes. Particularly with regard to specifying the media type of the linked resource (as in the MEDIA attribute in HTML 4.0). There is a need to develop an extensible repertoire of role types, with common semantics so that they can be recognized and acted upon appropriately by a variety of user agents. HTML 4.0 LINK for instance suggests a simple set of pre-defined names for PREV NEXT, TOC, etc. XLink could go beyond these simple conventions and provide a more formal set and mechanism.

Options for resolving the issue:

1. Do nothing.
2. The editors could write up some roles that are media-specific.
3. Other WGs could be polled for media-specific behavior.
4. Others...?

Resolution:

not say anything on this subject

Update:

c.f. [XL60]

[XL30] Event Association.

Association of events with links: the XLink specification provides no counterpart to the HTML 4.0 attributes which permit script events to be attached to links. This issue is also related to the DOM work and the desire to provide a device-independent means of specifying and activating events.

Options for resolving the issue:

1. Do nothing.
2. The editors could write up a proposal to include this functionality in XLink.
3. Others...?

Resolution:

Event association can be done by adding attributes on XLinks, make sure that the fact that attributes not with xlink namespace can be added to XLink constructs is clearly stated in the WD, with example(s).

Update:

c.f [XL52] and [XL60]

[XL31] Dealing with relative URIs in XLink.

Use XBase

[XL32] Dealink with XLinks without xlink:href

Shall we have xlink:href being #REQUIRED or #IMPLIED ?

Resolution:

on xlink:href being #IMPLIED and XLink WD to be edited to express that XLink processing should be stopped in the absence of xlink:href

[XL33] link-events:

Should XLink provide a counterpart to the HTML attributes that permit script events to be attached to links? This issue is also related to the DOM work and the desire to provide a device-independent means of specifying and activating events. We are inclined to let this be part of the application semantics of a language at a higher layer than XLink.

Resolution:

not to do anything

[XL34] arc-semantics:

There are no role or title attributes on arc elements because we felt that the role of any arc is the concatenation of the two end roles, and if you're going to display title text for an end, there's no sensible place to display the title text for an arc in addition. However, in cases where the relationship between two elements has a role, then this mechanism does not hold. For example, a family may have many members, and the arc between a one person and another person could have a daughter role, whereas the arc in the opposite direction could have a mother role. Should we allow arc elements to have roles and titles?

Resolution:

add role= and title= to arc

Update:

c.f. [XL75] Add an xlink:arcrole attribute

[XL35] require-xls-to-be-xml:

Is it possible, given the expectations of Web architecture, for us to make a conformance constraint requiring that resources identified as external linksets be of Internet media type */xml or some derivative?

Resolution:

it's an error if a resource which is asserted to be an external linkset is not an XML 1.0 document

[XL36] step-control:

From Ben: Should control over accessing nested external linksets be brought up a level, so that the "XLink processor" (whether that's a UA or a server-side application, or perhaps has no interaction with the end user at all) rather than the application is the place where steps may be limited? In what sense is the "processor" different from the "application"?

Resolution:

not saying anything about this and make wording consistent using "application"

[XL37] not-an-xlink:

Would it be good practice to dictate an explicit value to use to indicate that the element is not an XLink element, e.g., "none" or something?

Resolution:

we'll add the value "none" to the reserved set of xlink:type attribute values

[XL38] resource-media-specification:

Should XLink develop its own an extensible repertoire of role types, with common semantics so that they can be recognized and acted upon appropriately by a variety of user agents? HTML 4.0 LINK, for instance, suggests a simple set of pre-defined names for PREV NEXT, TOC, etc. XLink could go beyond these simple conventions and provide a more formal set and mechanism. We are inclined, in general, to leave this to higher-level languages based on XLink.

Resolution:

Dropped from XLink 1.0

[XL39] role-ns:

Does the Namespaces specification allow our creation of roles as a new "symbol space"? At the very least, does it not disallow it?

Resolution:

This issue is declared poorly framed and will be bypassed unless clarified with options.

[XL40] display-centric:

The behavior attributes are clearly quite display-centric, despite our attempts to them as being more generic. Can we motivate them in a less display-centric way?

Resolution:

There is a point here, but it is relatively low-priority. If improvements can be made without delaying publication of the spec, they should be.

[XL41] embed-where:

From Steve: The instructions for where to embed a resource are not perfectly accurate -- there may be no next content; more important, there may be element and other boundaries in between, and this definition leaves it ambiguous on which side of them embed happens. We should explain that the scope of the source anchor matters: if you linked to a SEC, the embed happens at the Point (as defined now in XPointer) immediately following the SEC; if you linked to the range consisting of all the children of the SEC, you'd get the embed just inside the end of the SEC after the last child (you could also get that by XPointing [a new verb!] to that point explicitly). This would matter, for example, if elements were generating text before or after themselves for display, or leading/trailing vertical space, or if the user is supposed to follow the link and then be able to edit, or.... How can this description be made unambiguous?

Resolution:

Intent: embedding occurs after the resource participating in the link. In the case of XML, the effect is clear [examples, maybe stolen from issue text]. If the resource is not XML, "after" has to be interpreted in light of the type of the resource.

[XL42] what-to-replace:

From Steve: A real issue we never resolved is the distinction in embed/new/replace semantics; we've left the intermediate case unnamed, where you want the destination anchor to replace the source *anchor*, not the source *document*; this makes a smooth sequence of 'what to replace': nothing (embed), the anchor (currently unnamed), the subresource (replace), or the window (new). Some might want to add something for panes, but that seems overkill (and hard to define consistently). Should the intermediate case be named and defined?

Resolution:

Good idea, doesn't need to be in XLink 1.0

[XL43] behavior-ns:

The final example in Appendix B implies that we have to leave the value space for show/actuate open, and that they have to be QNames just as role is! Is this acceptable? If so, the specification will require a bit of surgery to reflect this.

Resolution:

Resolved by previous decisions. QNames are OK

Update:

QName use for role was removed, [XL75] xlink:arcrole

[XL44] Inferred Link Types

Source: IG - http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Jan/0048.html

Also see referal back to the IG - http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Jan/0059.html .

Possible decisions: [http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Jan/0074.html ]

1. Make xlink:type required.
2. Define xlink:type="none" as "undeclaring" the construct as a link.
3. Both 1 and 2.
4. Leave it alone.

1. Make xlink:href optional (we already decided this once as XL32, see http://lists.w3.org/Archives/Member/w3c-xml-linking-wg/1999Nov/0038.html and http://lists.w3.org/Archives/Member/w3c-xml-linking-wg/1999Nov/0042.html ; is there a documented reversal of this decision?)
2. Leave it alone.

Resolution: Consensus on

1. the xlink:type attribute is required (possibly defaulted from the DTD)
2. the none value is allowed for xlink:type
3. xlink:href is optionnal on a simple link

The problem of handling naked href attributes (like in XHTML) is a separate issue [XL70]

[XL45] Conformance clarification: mandate legal prefixes in attribute values

Source: IG - http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Jan/0039.html

Summary: Suppose I have an implementation that only recognizes unqualified values for "show", and it encounters an XLink with the attribute show="badprefix:foo", where the badprefix does not correspond to a namespace declaration in the document. According to bullet #3 of the conformance statement, it looks like I have to check for this error even though my implementation will treat it as undefined anyway. This type of error does not enhance the user experience of certain applications like browsers. Should we create an exception for this type of error?

Possible decisions:

1. Allow processors which do not interpret qualified names to treat this as an undefined value.
2. Clarify that all processors must validate this value, even if they don't handle it.
3. Leave it vague.

Resolution:

We got no clear consensus so the result is to keep the current state of the drafts i.e. 2/

Update:

QNames are not used anymore for roles c.f [XL75]

[XL46] Don't imply self-referential links

Source: IG - http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Jan/0044.html

Summary: Implicit arcs exist from each resource to itself. This produces noise that prevents self-referential arcs from being used intentionally.

Possible decisions:

1. Remove implicit self-referential arcs.
2. 1 + prohibit all self-referential arcs.
3. Leave it vague.

Resolution:

In the case that a "to" is missing, there are explicit arcs from that resource to all others. Hence, the referenced paragraph is unnecessary and confusing and should be removed with appropriate editorial surgery.

Update:

Implicit arcs were dropped [XL22]

[XL47] Ineraction between xlink:external-linkset and xlink:show

Source: IG - http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Jan/0047.html

Summary: What is the interaction between xlink:role="xlink:external-linkset" and show="embed" or show="new" or show="replace"?

Possible decisions:

1. Place a constraint that show is to be ignored on external linksets.
2. Change syntax of external-linkset, e.g. make it a value of "show" instead.
3. Define what these combinations mean.
4. Leave it vague.

Resolution:

Option 1; "show" is ignored on external linksets. Actuate is ignored and treated as if "auto".

[XL48] Remove simple links

Source: comments list - http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0047.html

Summary: Simple links should be removed from XLink. Users who require simple syntax have the options:

1. transform a home-made syntax using XSLT
2. use smil:a, html:a or html:img

Possible decisions:

1. Remove simple links.
2. No change.

Resolution:

This is a previous decision of the WG; no dramatic new info or arguments. Keep them for now.

[XL49] Split show into two attributes

Source: comments list - http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0028.html

Summary: Suggests splitting show attribute into 2 attributes, the operation and the target. Also possibly add an html:show which is syntactic sugar for these new attributes.

Possible decisions:

1. Split show into two attributes.
2. 1 + add html:show
3. No change.

Resolution:

No support in the WG for adding this capability at this time. Good candidate for future enhancement, no architectural barriers to doing this in future.

[XL50] actuate inadequate

Source: comments list - http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0028.html

Summary: Actuate values are very display specific, which doesn't support multiple tiers of processing.

Possible decisions:

1. Move actuate to HTML namespace.
2. Replace actuate with an "activation-event" attribute.
3. No change.

Resolution:

No support in the WG for adding this capability at this time. Good candidate for future enhancement, no architectural barriers to doing this in future.

[XL51] add functionality similar to XInclude's "parse"

Source: comments list - http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0028.html

Summary: add "parse" functionality, or an even more powerful capability of indicating what processor to use to load the resource (which might be implied by type), as well as processor directives and/or a processor stylesheet url (which might be done some how as a complex xlink?).

Possible decisions:

1. Add "parse"-like functionality.
2. Add augmented "parse"-like functionality.
3. No change.

Resolution:

For the case of XML, this capability has explicitly been removed from XLink and placed in the XInclude work item now before the Core WG. Note that the show value is a QName, so you can introduce your own values from your own namespace to achieve media-type-specific semantics. Furthermore, you can add your own attributes to XLinks.

[XL52] request for events to be attached to xlinks

Source: comments list - http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0031.html

Summary: add scriptable event hooks to XLink

Possible decisions:

1. Add events.
2. No change.

Resolution:

Already considered and rejected for this release. [XL33]

[XL53] request for Xlink to use Schema

Source: comments list - http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0004.html

Summary: Xlink to use Schema

Possible decisions:

1. Editorial change to show examples of Schema syntax.
2. No change, immaturity of Schema prevents this.

Resolution:

Schema not yet sufficiently mature.

Update: see Schemas support [XL79]

[XL54] Clarifications of "embed" of an XPointer.

Source: comments list - http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0017.html

Summary: (Possibly XPointer issue?) Suggests that XPointers should operate differently when show="embed"? I (Jonathan) think this is more about what the meaning of an XLink with show="embed" of a nodes returned from an XML resource by XPointer. This type of thing is specified in XInclude.

Possible decisions:

1. Already addressed?

Resolution:

This is addressed in XPointer; some functionality with relation to the former "parsed" value now falls into XInclude.

[XL55] Request to move ranges to XLink

Source: comments list - http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0046.html

Summary: Ranges belong in XLink, simplifies XPointer implementations.

Possible decisions:

1. Duplicate issue?

Resolution:

Considered fully by the WG and rejected for reasons that are on the record.

[XL56] Use of QNames in Role isn't sufficient

Source: comments list - http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0020.html

QName attributes are not sufficient for roles, roles should be a standalone element. Dave Orchard does not fully understand rationale for the counter proposal. I think that the author of XL56 has missed the point of the role, that it's for applications to use with arcs. In particular, I think the author gets confused about the use of role in a simple link.

Possible decisions:

1. DaveO preferred: Assign a resource to examine issue for
2. Assume DaveO has summarized the issue correctly - confusion on authors part - and ignore
3. Same as previous but drop role from simple links to prevent confusion as there is no arc construct in simple links.

Resolution:

Issue superceeded by subsequent development see [XL75]

[XL57] Editorial comments

Source: comments list - http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0021.html, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0005.html, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0008.html

Summary: 3.1.3 says the title element is called "locator".

Possible decisions:

1. Editorial fixes.

Resolution:

Addressed in the recent draft

[XL58] Rename Locator

Source: comments list - http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0006.html

Summary: Locator become Remote and Resource become Local.

Possible decisions:

1. Revisit naming.
2. No change.

Resolution:

no change, doesn't dramatiquely improve it and people are used to existing terminology

[XL59] Make role nmtokens

Source: comments list - http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0008.html

Summary: Make role nmtokens so that a resource could be used by multiple Arcs.

Possible decisions:

1. Make role nmtokens.
2. No change.

Resolution:

good idea but too late for 1.0 see also [XL84]

[XL60] Drop element syntax

Source: comments list - http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0008.html

Summary: Drop element syntax.

Possible decisions:

1. Already handled.

Resolution:

done, accepted

[XL61] Arc clarification

Source: comments list - http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0008.html

Summary: The text in section 3.1.4 be revised from "locator-type element" to "locator- or resource-type element".

Possible decisions:

1. Make change (editorial?).
2. No change.

Resolution:

Fixed, done.

[XL62] Underdefined Linksets

Summary: In section 3.1.5 and other areas, the concept of an "external linkset" is underdefined. Specifically, the interaction of the external linkset with other behaviour-based information (such as show="", etc.) is undefined.

Possible decisions:

1. Do nothing.
2. Instruct the editors to explore the interaction of external linksets with behaviour-based attributes, and define conformance rules. The problem with this approach is that it does create error conditions -- e.g. if an external linkset shouldn't be used with show="foo", then aren't we creating a situation that demands an error?
3. Remove the concept of external linksets.

Resolution:

substancially adressed in recent draft

[XL70] Attribute recognition in XLink

Summary:

Right at the moment, Xlink provides only one way to recognize its attributes: place them in the xlink namespace. So a simple link looks like

<someTag xlink:type="simple" xlink:href="whereToGo">

One problem with this is that it makes it difficult [impossible?] to grandfather HTML links, because in

<html:a href="whereToGo">

the href is not in any namespace, and cannot be in any namespace while still conforming to HTML rules.

So... we could assert that if it says "xlink:type", then all other xlink attributes are recognized if they're in either the xlink namespace or not in any namespace; so

<a xlink:type="simple" href="whereToGo">

is an xlink; and if you default the xlink:type value in the internal subset, you're left with

<a href="whereToGo">

and HTML links are now Xlinks, hurray! hurray!

On the other hand, if Xlink is going to recognize "naked" href attributes, what about naked "role" "show" and "title" and so on; this severely gets in the way of language designers who can't turn something into an xlink without having it grab a bunch of attributes.

Another suggestion is due to Steve DeRose; it is an intermediate position, whereby xlink can signal whether or not it should process non-namespaced attributes. This could either be done with another value of the "xlink:type" attribute or with another attribute.

<a xlink:type="simpleAndHungry" href="whereToGo"> or

<a xlink:type="simple" xlink:eatNakedAttributes="true" href="whereToGo>

and with attribute defaulting, either could be the HTML we know and love.

The XLink WG has already rejected the "always eat naked attributes" proposition a couple of times, and I doubt it would be fruitful to re-open this.

However, the intermediate position described just above did gather quite a bit of WG-member support.

It seems like a pretty straight cost-benefit tradeoff. Grandfathering HTML is good, and arguably in our requirements. Adding new syntax has a cost.

Possible decisions:

1. Keep as is
2. Recognize naked attributes on xlink elements (i.e. elements carrying xlink:type)
3. Provide a mechanism like a separate attribute allowing document/dtd designer to decide on a case by case basis

Resolution:

Not effective consensus on adding naked attribute support on XLink

=> The WG is not meeting requirement on this issue (HTML and SMIL) c.f. [XL78] and [XL83]

Followup: this generated a CR exit criteria constraints of showing how this could be achieved using XML Schemas. The criteria was met by publishing a NOTE XLink Markup Name Control showing an example of Schemas fragment using types to carry the XLink semantic and how to import it when defining a Schemas for a new vocabulary, allowing in effect to associate XLink semantic to any attribute.

[XL71] embedding when resources are sets of locations

Source: Erik Wilde feedback http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0054

Summary: the problem of embedding when the starting and/or ending resources are sets of locations. Actually, the problem isn't strictly limited to embedding behavior; there are questions no matter what the traversal behavior is. We need to decide what to do about this...

Possible decisions:

1. Ignore
2. Provide a better description
3. Provide example(s)

Resolution: Here is a rationale for handling set of locations:

• starting resource is singular ending is multiple: handle all ending locations in sequence
• starting resource multiple, ending sigular: process the ending resource as a succession of single traversal (foreach)
• both multiple: for each source, do a processing like a single source.

The draft will be updated with a precise description

[XL72] legal-implications

Source: Eve Maler feedback when presenting at XTech2000 http://lists.w3.org/Archives/Member/w3c-xml-linking-wg/2000Mar/0000.html

Summary: I just wanted to record this, so we don't lose it for V2.0. In my class we spent a little time talking about the legal implications of "embedding" someone else's stuff. (This isn't a problem unique to XLink, since HTML IMG has it too, but because XLink lets you embed XML content, the issue rises in importance.) Two years ago, Steve DeRose and I batted around an idea for how to protect document authors from unauthorized transclusion, based (I believe) on an idea that originally came from Ted Nelson. The idea is to add an attribute that contains the URI of a permission-granting authority, with a default that presumes you have obtained permission if necessary. I'll let Steve chime in with the details

Possible decisions:

1. Out of scope
2. Add such a mechanism now
3. Only for 2.0

Resolution: 3/ it is not really one of our requirements, not for V1. However this is an important issue

Suggestion: Add a PI, similar to the robots PI, that says "Don't transclude me" (that is, don't embed any of my content)

[XL73] multiple-onLoads-with-show-replace

Source: Eve Maler feedback when presenting at XTech2000 http://lists.w3.org/Archives/Member/w3c-xml-linking-wg/2000Mar/0000.html

Summary: If you have a document with more than one onLoad arcs starting from it, and show="replace", how do you handle this? It's easy to see what to do with show="new" (open a bunch of windows) and show="embed" (augment the content in a bunch of places), but if show="replace", our processing model is underspecified with regard to what "loading" means.

Possible decisions:

1. Do not specify this behaviour
2. Forbit replace for multiple target
3. Suggest to handle it like 1 replace and (n -1) new
4. only the first show="replace" actuate="onLoad", going in document order, be traversed

Resolution: A minimalist definition of the behaviour in that specific case will be added to the specification. DavidD to provide it, done. Is this really closed @@ ?

[XL74] external-linkset-spelling

Source: Eve Maler feedback when presenting at XTech2000 http://lists.w3.org/Archives/Member/w3c-xml-linking-wg/2000Mar/0000.html

Summary: To be consistent, the role value "<prefix>external-linkset" should be spelled "<prefix>externalLinkset".

Possible decisions:

1. keep existing spelling
2. Make the change

Resolution: 2/ we should use camel case spelling. So change it to externalLinkset

[XL75] Add an xlink:arcrole attribute

Source: Ron Daniel, after feedback on Eve Maler presentation at XTech2000 http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Mar/0003.html

Summary: an xlink like the following:

 ...as discussed in [<a xlink:type="simple"
    xlink:href="...some URI...">Smith95</a>]...

Cannot be mapped to RDF we need a role. But if we just add xlink:role to the link above, the role is describing the ending resource, not the relation between the start and end of the link. There seem to be a couple of arguments for it. It reduces the number of ways we are overloading "role", and it lets simple links provide roles on arcs as well as roles that provide type information about the resource at the destination of a link. The example might become:

 ...as discussed in [<a xlink:type="simple"
    xlink:href="...some URI..."
    xlink:arcrole="arg:rebuttedBy"
    xlink:role="doctoralThesis">Smith95</a>]...

There are also at least a couple of arguments against it. One is quite simply that its late in the game and maybe we really don't need this. If people want to map to RDF they will be happier with extended links anyway. Second, and more serious, is that it is going to take some real concentration to develop a good mapping to RDF, and what we do in haste now we can regret in leisure in the future. For example, what is the starting resource in the example above? The string "Smith95"? But in RDF, properties don't originate from strings, they originate from resources. So do we use an XPointer that addresses the occurrence of "Smith95"? Or do we say the entire starting document is rebutted by Smith95.

Possible decisions:

1. drop it, simple links must stay simple
2. Postpone to 2.0
3. Add this as an optionnal attribute

Resolution: 3/ adding xlink:arcrole to simple links

[XL76] Add a robot PI

This issue was raised by Walter Underwood on the 21st of March:

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

He wants:

A "robots PI", as described at http://homepages.go.com/~wunder0/robots-pi.html.

Options:

1. Add the robot PI as described.
2. Add the robot PI with modifications.
3. Do not add the robot PI.

Decision: 3/ not added. 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. Reply sent.

[XL77] DOM WG Comments

Lauren Wood, of the DOM WG, raised the following issues:

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

1) DOM doesn't handle qualified names in attributes. They are concerned that this is problematic.

2) In 3.1.3, XLink uses a URI/local name pair, without specifying the syntax, and there is a possibility that the prefix was meant, rather than a namespace URI/local name pair. This should be clarified. Given the way the DOM models namespaces, using URI and local name actually makes more sense (where possible) than using a prefix.

3) 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.

Resolution: This is really based on a particular type of XLink implementation and discussing non normative behaviour.

4) 3.6.1 - Prefix-in-attribute-value; the "show" attribute contains a QName, whose prefix must be declared but must not reference XLink's namespace. This is a specific instance of our concerns with prefixes and namespace. There also seems to be a descriptive conflict here when it says that other values "must" be interpreted as "undefined".

5) 3.6.1. embed: - 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: 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.

Decision: 1) 2) and 4) are about the use of QNames in some attributes. This is currently being discussed in the IG.

Resolution on 1) 2) and 4): QName use in attributes is removed, this was done in two steps:

1. Resolution1: role was used as both a label to associate locators and arcs and as a way to carry the semantic informations. This is now splitted as two attribute to separate each function. There is a new "arclabel" attribute on arc elements.
2. Resolution2: QName use is dropped. The attributes "role" and "arcrole" are now URI only

[XL78] SYMM WG Comments

Aaron Cohen, of the SYMM WG, raised the following issue:

http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0082.html

Basically, the SYMM WG feels that the XLink WG didn't meet its requirement to produce a syntax that would allow for recognition of XLink-style semantics on foreign elements, such as SYMM and HTML.

Options:

1. Add a note to the Draft affirming that this is an issue for future versions of XLink. Ben Trafford prefers this option.
2. Add a note about the problematic nature of grandfathering existing specifications. Note that this does fly in the face of our requirements, which would then require more explanation.

Resolution: Add wording to the DoC. This issue relates to [XL70] and we provide the same answer

[XL79] Schema WG Comments

C. M. Sperberg-McQueen, of the Schema WG, raised the following issue:

http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0081.html

The Schema WG believes that the specification would be stronger and XLink applications would be more interoperable if a XML Schema for Linking were included in the specification. Since this would not change the XML document syntax nor the processing implementations they request that this be done during the Candidate Recommendation period.

Options:

1. Add the schemas to XLink, with the help of a liaison from XML Schema. Ben Trafford prefers this option, especially if the schemas are put into an appendix.
2. Don't add the schemas, since XML Schema is not yet a W3C Recommendation. This seems rather weak, especially in light of the Director's request for schema support by other WGs. http://lists.w3.org/Archives/Member/w3c-xml-plenary/1999Nov/0008.html

Resolution: 2/ This was already decided previously [XL53]. The WG noted it was not needed right now, but it's a good idea we will try to build it during CR stage.

[XL80] I18N WG Comments

Martin Dürst, of the I18N WG, raised the following issue:

http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0079.html

1) The definition of "URI reference" should be changed to make sure that the provisions of http://www.w3.org/TR/charmod/#URIs are taken into account. This applies to the definition just before Section 2, and to Section 3.4. [as already discussed in another forum, the provisions should be included in the XLink spec rather than being referred to]

2) 3.1.4: 'multiple titles are necessary for internationalization purposes': This sounds good, but it should be clearly defined how these are supposed to be selected (e.g. say something like: If multiple title elements are present, and they have different values of the xml:lang attribute, then for display,... the language variant that is most suited for the user should be choosen). (for further details, a pointer to the HTTP spec or the SMIL 1.0 spec would also help).

Options for XL80:1:

1. Don't add the definition of a URI-reference. Linking to the reference is sufficient. Ben Trafford prefers this option.
2. Add the definition. Linking is insufficient.

Suggestion:

Cover the Character Model URI provisions. Eve's recommendation: Based on what we've done for XPointer and further conversation with Martin, it's best to restate the Character Model draft's description of proper URI encoding; however, don't define the parts of a URI reference, but rather rely on the reference to RDF 2396 for this. Provisional status of the spec: Section 5.4, Locator Attribute (href), goes into detail only about the tricky character encoding stuff a la XPointer, but does not define URI reference internal structure.

Options for XL80:2:

1. Add the appropriate text, because Martin has a good point. Ben Trafford prefers this option.
2. Don't add the text. This doesn't appear to be a reasonable option, since, well, Martin has a good point.

Suggestion:

Give guidance on how to select different titles based on language or locale. Ben's recommendation: Add the suggested text, because Martin has a good point. Provisional wording in the spec (5.1.4 Titles for...), which motivates title elements better but does not do what was asked for: "One common motivation for using the title-type element is to account for internationalization and localization. For example, title markup might be necessary for bidirectional contexts or in East Asian languages, and multiple titles might be necessary for different natural-language versions of a title." I have neglected to add Martin's recommended wording in the 20000418 version, but plan to in the next one.

Resolution: Follow Eve suggestion and reuse Martin wording :

"If multiple title elements are present, and they have different values of the xml:lang attribute, then for display,... the language variant that is most suited for the user should be chosen). (for further details, a pointer to the HTTP spec or the SMIL 1.0 spec would also help)."

[XL81] Martin Dürst Comments

Martin Dürst raised the following issue:

http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0080.html

1) Only RFC 2396 should be cited, or RFC 2396 should be clearly identified as normative, whereas the other URI-related RFCs should be clearly identified as obsolate.

2) 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. A similar problem happens in the Note before the example before 3.1.1: the meaning of the note is very unclear until much later.

3) 'CompSci' as a title value should be expanded to 'Computer Science'. Otherwise, it may be difficult to guess for people without English mother tongue.

4) In 3.1.3, 4. paragraph, there is a spurious space that is part of the link after (show and actuate).

5) The use of 'cname's for roles is frightening. Using URIs directly would simplify things a lot.

Options for XL81:1:

1. Martin appears to have a good point. We could alter the existing references.
2. Someone comes up with a good reason for why RFC 2396 doesn't render other related specs obsolete.

Recommendation:

Remove references to RFC 1738 and 1808; leave only 2396. Eve's recommendation: Do this because the two are out of date. Provisional status of the spec: All references to the bibliography entries for 1738 and 1808, along with the entries themselves, have been removed.

Resolution: agreed with recommendation

Options for XL81:2:

1. A referential DTD could be placed as an appendix, uniting various examples used in the document. This appendix could be referenced early on in the document. Ben Trafford prefers this option.
2. We do nothing.

Recommendation:

Attribute defaulting is confusing. Eve's recommendation: Take this entire suggestion. Provisional status of the spec: In Section 5.1, the Note before the example has been removed, and the example is now a complete version, with bits of it being excerpted in all the sections that follow.

Resolution: agreed, with the comment and Eve suggestion. The WG trust Eve to clarify the example.

Options for XL81:3:

1. Martin is absolutely correct. We should change this. Ben Trafford prefers this option.
2. Someone explains why Martin isn't absolutely correct, and we don't change this.

Recommendation:

Expand "CompSci" to "Computer Science." Eve's recommendation: Do this. Status of the spec: I neglected to do this in the 20000418 version, but plan to do it in the next one.

Resolution: agreed

Options for XL81:4:

1. Martin appears to be correct. This needs to be fixed. Ben Trafford prefers this option.
2. Someone explains why Martin isn't absolutely correct, and we don't fix this.

Recommendation:

Can no longer find the example where the spurious space appears. (The section numbers and examples were both heavily reorganized.)

Resolution: dropped due to reorganization of the specification, the problem don't show up anymore

Options for XL81:5:

1. This issue is directly referring to the use of Qnames in roles. This is addressed by XL77.

Recommendation:

Don't use QNames for roles. This was decided and implemented last week.

Resolution: agreed, already done in the last draft

[XL83] HTML WG Comments, Part 1

Steven Pemberton, of the HTML WG, raised the following issue:

http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0073.html

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 proposal in Steven's mail could leverage the current Xlink proposal to create a description language that does meet the original requirements, without needing too much extra work or time.

The proposal is detailed in Steven's mail.

Options:

1. As with the SYMM WG comments, determine that this work should be put off to a future version of XLink. Note that this would be reopening a closed issue, as well as adding significant new text to the current draft. Ben Trafford prefers this option.
2. Consider Steven's proposal, and possibly use it, or modify it and use it.
3. Come up with a different syntax altogether.

Resolution: Add wording to the DoC. This issue relates to [XL70] and we provide the same answer

[XL84] Multiple Roles

Philippe Le Hegaret raised the following issue:

http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0070.html

He would to know if the issue of having multiples roles on the role attribute (and from/to attributes) has been considered by the linking WG. He notes that this is only a syntactic issue and it doesn't change anything in the semantic of XLink.

Options:

1. Multiple roles can be handled in the specific document instance. We don't need to define them. Ben Trafford prefers this option.
2. We can define a syntax for multiple roles, as suggested by Philippe.

Resolution: Not for version 1.0, schema may help do this in the future. This issue was already decided [XL59]

[XL85] Editorial Nits

Dan Connolly made the following suggestions:

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

1) Move section 4. "Processing and Conformance" before section 3. As it is, while reading thru the spec, until he got to section 4, he didn't know the focal point of the spec, and he wasn't really sure which end was up.

2) Also, move the may/must RFC2119 para under the conformance heading, and move 1.3 Terminology under there too. This will make the separation between the "fluffy" stuff in section 1 and 2 and the more formal stuff that's now in sections 3 and 4 more clear.

3) Dan suggests that we review to be sure that we are actually using the may/must/should terminology consistently. I suggest you do that, and mark up such occurences ala may in the generated HTML...maybe use CSS smallcaps in the stylesheet. Currently, there are several occurences of "can" that seem like they are intended in the RFC2119 sense of "may"; e.g. in 2.3 Attribute Value defaulting: "attribute defaults (fixed or not) can be added to a DTD..." .

4) Continuing down that list, Dan suggests moving [Definition: ] arc into the context of section 3.1.3 "Traversal rules ...". If we want to collect the terms and definitions into a glossary, very well, but Dan thinks that we ought to make that glossary refer to the definitions in context, rather than trying to make it stand on its own. Dan prefers such a glossary to go at the end, ala an index, but putting it up front is OK as long as the forward references are clear.

Options for XL85:1:

1. Move the section. This seems to make sense, but might require fairly significant editing.
2. Don't move the section. Ben Trafford prefers this option.

Options for XL85:2:

1. Move the indicated portions to where he suggests. This doesn't seem to require much editing overhead, and does appear to clarify things.
2. Don't move the indicated portions.

Options for XL85:3:

1. Check the document for correct usage of the conformance terminology, and alter the appearance of it. Note that this might require a change to the XMLspec DTD, to represent inline elements that refer to conformance text. Ben Trafford prefers this option.
2. Check the document for correct usage of the conformance terminology, but don't alter the appearance of it.

Options for XL85:4:

1. Move the glossary to the end.
2. Move the glossary to the end, and change the location of the arc definition.
3. Just change the location of the arc definition. Ben Trafford prefers this option.
4. Change neither.

Suggestion:

All of Dan's suggestions have been provisionally done; basically, the reordering of chapters was undertaken to put Conformance stuff before the substantive XLink markup stuff, the glossary was turned into a Concepts section, and syntactic terms are defined when used. Eve really likes it. :-)

Resolution: the WG agreed with Dan's comments. Eve already implemented the changes.

[XL86] Henry Thompson's Technical Concerns

Henry Thompson had the following technical concerns:

http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0067.html

1) 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 -- complain, halt and catch fire, what?

Suggestion:

Henry is asking what applications should do when they don't "observe the mandatory conditions." This is a statement of what an application must do to be considered conforming, so there is no prescribed behavior when an application doesn't conform. There are few mentions of "must" application behavior anyway (allowing the suspension of linkbase list processing, ignoring behavior attributes on linkbase lists).

Recommendation: No change.

If Henry is, rather, asking what the prescribed behavior is when an application performs "markup testing" (think of it as XLink-specific validation), we don't say. Should we?

Ben's recommendation: "Don't define error conditions, as it would require huge amounts of text and has been the source of contentious disagreement in the WG."

2) 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 too strong a requirement in the case where the document in question contains no linkset information.

Suggestion:

Ben's recommendation: "Modify the definition of 'application' to exclude 'linked-from' documents. Such a definition could be: 'An XLink application is any software module that interprets XML documents containing XLink links. This specification defines conformance requirements for XLink applications.' Provisional wording in the latest spec (3.3, Application Conformance): "An XLink application is any software module that interprets well-formed XML documents containing XLink elements and attributes ..."

3) Henry 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, or what.

Suggestion:

Ben's recommendation: "Reference the Infoset definition of an Element Information Item." Provisional wording in the latest spec (3.3, Application Conformance, continuing from the ellipsis in the above paragraph): "..., or XML information sets [XIS] containing information items and properties corresponding to XLink elements and attributes. (This document refers to elements and attributes, but all specifications herein apply to their information set equivalents as well.)"

4) Henry thinks that if you're going to describe the 'show' attribute as having QNames as values, then ignoring the default namespace declaration is a serious mistake. If it's a QName, then its qualification is determined by XML Namespace REC rules. If its qualification is _not_ determinied by those rules, it's not a QName. He thinks we have several options:

1. Describe it as a union of {new,replace,embed,undefined} with QName, with a hack explaining that in cases where there's no default NS declaration in scope the ambiguity is resolved in favour of the privileged interpretations;
2. Describe it as a QName, and reserve the un _qualified_ versions of new,replace,embed,undefined. This would mean if there is a default NS declaration in scope, you'd have to switch it off with "xmlns=''" before you could specify the special values;
3. Describe it as a QName, and switch to using xlink:new, xlink:replace, xlink:embed, xlink:undefined.
4. Combine (b) and (c), i.e. reserve _both_ (unqualified) 'new' and 'xlink:new', etc. This would give us a way of avoiding the necessity of undeclaring the default NS.

5) Henry notes that the concerns raised in section 2.5, and in particular the issue of legacy 'naked' href, can probably be addressed by XML Schema. Henry hopes the timing is such that we can include an XML Schema for XLink in the REC.

6) 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.

Options for XL86:1:

1. Define conformance for XLink processors.
2. Don't define error conditions, as it would require huge amounts of text and has been the source of contentious disagreement in the WG. Ben Trafford prefers this option.

Options for XL86:2:

1. Modify the definition of "application" to exclude "linked-from" documents. Such as definition could: "An XLink application is any software module that interprets XML documents containing XLink links. This specification defines conformance requirements for XLink applications. " Ben Trafford prefers this option.
2. Don't modify the definition.

Options for XL86:3:

1. Reference the Infoset definition of an Element Information Item. Ben Trafford prefers this option.
2. Define what we mean by "element" in some other fashion.
3. Don't define what we mean by "element."

Options for XL86:4:

1. There are no clear options yet, as the WG and IG are discussing this issue.
2. This is related to the use of QName. we don't use them anymore

Options for XL86:5:

1. While Henry's point about XML Schema taking care of these issues is well-taken, XML Schema is not a recommendation as yet, and as such, our issues should stand in the document. Ben Trafford prefers this option.
2. Henry is completely correct, and we should drop these issues from the document.

Options for XL86.6:

1. drop, external linksets are extended links, XLink conforming applications must handle extended links anywhere in the document, including the case of external linksets.
2. define a new syntax for external linksets c.f [XL90]

Resolution:

1) rejected ... however We should keep the word "must" and add a clarifying note of what it We should keep the word "must" and add a clarifying note of what it means to not meet a "must" in XLink specification.

2) Accepted, the definition in section 3.3 has been changed to avoid that problem

3) 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.

4) Accepted, the definition of these attributes have been changed. The original role attribute has been split into two attributes, role and arcrole containing URI references. The show and actuate attributes must pertain to a reserved set of predefined values. The Working Draft 18 April 2000 (members only) @@ reflect those changes

5) Dropped 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 developped more during Candidate Recommendation phase, hoping that support of attribute remapping will be possible.

6) Drop, external linksets are extended links, XLink conforming applications must handle extended links anywhere in the document, including the case of external linksets. However add the following sentence to 5.1.5 Locating Linkbases at the end of the 4th paragraph: "To ease XLink processing, document creators may wish to define linkbase arcs near the beginning of a document."

[XL87] Henry Thompson's Editorial Concerns

Henry Thompson had the following editorial concerns:

http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0067.html

1) All the contributing systems mentioned in 1.1, including HyTime and TEI as well as Dexter etc., should have references.

Recommendation:

Make bibliography references to HyTime, Dexter, etc. Done.

2) Please clarify the interaction of xlink:href and XBase. In particular, Henry can't tell whether
<foo xlink:type="simple" xlink:href=""> is always OK, always broken or depends on XBase.

Recommendation:

Clarify the interaction of xlink:href and XML Base, especially when xlink:href="". Eve's recommendation: No action needed, because "" is not a relative URI; rather, it always means the resource in which the "" value appears.

Provisional status of the spec: No change.

3) The second figure in 3.1.5 has xlink:extended-linkset where it should have xlink:external-linkset.

Recommendation:

Misspelling of external-linkset. Obsoleted by naming changes.

4) 3.4: "The URI-reference must be receive" -> "The URI-reference must receive"

Recommendation:

"be receive". Famous typo, fixed long ago.

5) last line in 3.6 intro above 3.6.1: "actuated=" -> "actuate="

Recommendation:

"actuated" typo. Fixed.

Options:

1. Accept some or all of Henry's comments. Ben Trafford would prefer all.
2. Accept none of Henry's comments.

Resolution: Accepted all points have been corrected. The handling of xlink:href="" is defined in RFC2396, some prose was added to section 5.4 to clarify its meaning.

[XL88] Terminology Issues

Bob DuCharme had the following terminology concerns:

http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0058.html

1) Since we allow for XML links to exist that are not defined as XLinks, then when we refer to HTML links in section 1.1 we ought to say: "automated translation of HTML links to XLink links."

2) "Document creators can use the XLink global attributes to make the elements in their own namespace." What does we mean by "make"? Isn't there a more appropriate verb to use here?

3) Bob believes that we should reinforce the idea of simple links as being subsets of extended links, rather than different links altogether.

Options for XL88:1:

1. We ought to make this change, since it's very obviously a clarification. This would, however, reflect diverging from our requirements document. Ben Trafford prefers this option.
2. We don't make the change.

Options for XL88:2:

1. We could rephrase this as: "Document creators can use the XLink global attributes to instantiate the elements in their own namespace." This might be clearer. Ben Trafford prefers this option.
2. We leave it as is.

Options for XL88:3:

1. This would require fairly significant rewrite. The spec is clear enough on this issue. Ben Trafford prefers this option.
2. We reaffirm that simple links are different than extended links, and modify the text to reflect that.
3. We reaffirm that simple links are different than extended links, but leave the text alone.
4. We leave the text as is.

Resolution: Accepted, though the comment was targetted at an older version. New version of the spec implement the changes, which were accepted c.f. http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0060.html

[XL89] HTML WG Comments, Part 2

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

Summary: 8 technical and editorial issues

1. Abstract rewording: s/describe/describe behavior similar to/
2. 2 Xlink markup design: removing the title attribute ?
3. 3 Xlink elements and attributes: 'linkset' used here but not defined
4. 3.1 last example is hard to understand
5. 3.1.1 the term 'local resource' is confusing, use 'contained resource' instead ?
6. 3.4 Locator attribute: typo, maformed sentence
7. 3.5 Semantic attributes: QName (done), title attribute to be removed
8. 3.6 Behavior attributes: s/show/effect/ , semantic of show too vague, explicitly note that 'embed' covers non-visual embedding (scripts).

Resolution:

1) Accepted replace "structures that can describe the simple unidirectional hyperlinks of today's HTML" with "structures that describes links similar to the simple unidirectional hyperlinks of today's HTML, ...."

2) Dropped: the definition of the title attribute and elements have been refined in accordance with the I18N working group. They are optional, if another title construct get normalized it will be easy to use it on XLink construct. In the meantime XLink will provide it's own optional construct.

3) fixed

4) fixed example was rewritten, and there is only one course element at most

5) Dropped: definition in 2.3 is here to define the terminology precisely

6) Fixed

[XL90] Linkbase lists as first-class citizens

Source: Eve Malerhttp://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Apr/0060.html

Summary: The topic of whether linkbase lists (previously called external linksets) should have their own element type is (re)opened

Once upon a time, this had its own element. Last year, it was folded into the extended link element, and was given a special role value so that the two could be told apart. In March, fresh from XTech where I got a related suggestion, I promised/threatened to put forth a proposal for making it separate again. Here it is, finally.

Sample declarations:

<!-- Has only the type attribute; contains locators -->
<!ELEMENT lbl (linkbase*)>
<!ATTLIST lbl
   xlink:type      (linkbaseList)          #FIXED "linkbaseList">
<!-- Same attribute list as for all locator-type elements -->
<!ELEMENT linkbase EMPTY>
<!ATTLIST linkbase
   xlink:type      (locator)               #FIXED "locator"
   xlink:href      CDATA                   #REQUIRED
   xlink:role      CDATA                   #IMPLIED
   xlink:title     CDATA                   #IMPLIED
   xlink:label     NMTOKEN                 #IMPLIED>

Sample instance using these declarations:

<lbl>
   <linkbase xlink:href="linkbase1.xml" />
   <linkbase xlink:href="linkbase2.xml" />
   <linkbase xlink:href="linkbase3.xml" />
</lbl>

Pro:

• Makes linkbase lists distinct from extended links; since linkbase lists are not a kind of extended link, but rather a kind of "packaging metadata" similar to a stylesheet linking PI, this seems appropriate. (If they were a kind of extended link that meant "traverse from this document to all the referenced documents," then another remote resource would need to be added that points to this document's root, and arcs would need to be defined from it to each of the others in turn.)
• Allows linkbase lists not to have the baggage of irrelevant features: traversal arcs/behavior, link roles and titles, and local resources. (Reusing the existing locator-type element means we have to allow irrelevant roles, titles, and labels on them; an alternative is to define yet another element type for linkbase items, but it doesn't seem warranted.)
• Can get rid of the need to define a single special role value just for linkbase lists. Any future XLink infoset or DOM can refer to this thing directly as a first-class citizen, and XLink no longer depends on role processing.

Con:

• Adds one more element type to the language, for a total of 7
• Makes a relatively substantial change late in the game

Check the thread called Linkbase list as first-class citizen: a proposal

Possible decisions:

1. Keep as is
2. Jump and make the change

Resolution:

- We should not say that the linkbase is loaded automatically but be processed depending on the value of the value of the xlink:actuate

- we should add an example

[XL91] XML infoset enhancements

Source: Eve Maler http://lists.w3.org/Archives/Member/w3c-xml-linking-wg/2000Apr/0085.html

Summary: An XLink infoset could be a WD or Note separate from the XLink spec, and on a different schedule, so it's not impossible to imagine our tackling this. Until we could sync them up somehow in a later version, the infoset could be an important advisory adjunct to XLink, much as the XML Infoset spec is. I've seen some of the havoc that lack of an infoset has caused XML, and it would be great to avoid it here. Also, the IG doesn't seem overwhelmed at the moment, now that the bulk of the design work is done, so I would argue they have the cycles.

I don't advocate turning XLink into a "transformational technology"; it shouldn't affect the infoset property values of any source XML document that contains a link or a starting resource. Rather, I want us to consider creating a data model that describes the information items and properties that XLink applications produce.

My main reason is that the exigencies of XML force us into a certain expression of links, but conforming XLink applications actually need to translate this into "native" linking terms in order to implement whatever behavior is called for, or at least pass the info on to a downstream app that does the real work. This should increase interoperability, so that you could more easily plug different basic XLink implementations into an application framework.

As an example of how XML and XLink "native models" differ, a starting resource for a third-party (out-of-line) link may be invisible to an XLink application unless it has been fed the appropriate linkbase. The XLink model of a document containing the starting resources will report nothing in one case, and something very significant in the other. This is markedly different from the raw XML infoset for a document that you would get out of a parser.

Some counter-arguments:

I realize that even though XLink isn't a huge language, this isn't a trivial piece of work. If we *had* developed an infoset simultaneously with XML 1.0, it never would have been delivered on time. Also, if we do want to include it in XLink itself, it's useful to remember that coverage of infosets can seriously bulk up a spec (witness XML Schema Part 1).

Check the thread XLink infoset: worth discussing?

Possible decisions:

1. No this is out of our charter
2. Yes start the discussion on the IG
3. Wait until our specification are in Candidate REC stage to start new work

Resolution: Wait after REC, not in 1.0

[XL92] providing checksum on locators

Source: [XPR4] Checking the resource content

Summary: by adding a mechanism to provide a checksum on a locator we would fullfill our requirement from XPR4

This was discussed on the IG list.

Possible decisions:

1. Drop this, nobody asked for it during Last Call
2. Add an optional attribute for the MD5 of the target resource

Resolution: not in XLink 1.0. Current developements in XML Dsig may provide the mechanism for us.

[XL93] "Multiple nodes" problems

Source: James Clark http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0186.html

Summary: language is unclear

language is unclear

why the behavior is supposed to be different for starting vs. ending resources

how ranges and points are to be handled

At first the WG believed it was linked to XL98, but James provided a more elaborated request:

I also don't think XL93 is the same as XL98. 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.

Possible decisions:

1. Improve the language wording toward a precise definition
2. Unify handling of source and ending resources

Decision: 2/ update the specification to say that the treatment of multiple node starting resources is application dependent

[XL94] Presentation of ending subresources is unclear

Source: James Clark http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0186.html

Summary: Presentation of ending subresources is unclear

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?

        

At first the WG believed it was linked to XL95, but James provided a more elaborated request:

I don't think XL94 is the same as XL95. 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.

Possible decisions:

1. Improve the language wording toward a precise definition
2. Explain taht the presentation context for an embedding resource is application-dependent.

Decision: 2/ update the specification to say that the presentation of embedded resources is application dependant.

[XL95] Presenting an Ending Resource in a Larger Context

Source: XSL/XML Linking Task Forcehttp://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0170.html

Summary: adding link metadata that will let link authors specify their desired values for Processing and Presentation Context as necessary

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

Possible decisions:

1. Add this to the TODO list for next version of XML Linking

Decision: Deferred, adding this at CR is not reasonable, not in v1.0, TODO list for next version of XML Linking

[XL96] Choosing a Stylesheet to Use for Presenting an Ending Resource

Source: XSL/XML Linking Task Forcehttp://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0170.html

Summary: adding link metadata that will let link authors specify their desired stylesheets

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

Possible decisions:

1. Add this to the TODO list for next version of XML Linking

Decision: this was already raised in the past, deferred, adding this at CR is not reasonable, not in v1.0

[XL97] Behavior of Multiple onLoad/replace Links in a Document

Source: XSL/XML Linking Task Forcehttp://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0170.html

Summary: recommend that the first onLoad/replace link encountered by an XLink application in the course of presentation be processed.

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

Possible decisions:

1. Change the definition of that specific processing problem to be application dependant.

Decision: change the Multiple onLoad/replace Links in a Document are handled in application dependant way

[XL98] Non-Well-Balanced and Discontiguous Ending Resources

Source: XSL/XML Linking Task Forcehttp://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0170.html

Summary: only requiring that if some ending resources are presented, then all must be made accessible to the user

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

Possible decisions:

1. Yes change the specification to drop that concatenation suggestion
2. keep as is

Decision: Accpted modifiy the description of the problem stating that it is application dependant, remove "concatenation"

[XL99] Editorial: Missing text

Source: David Olson http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0010.html

Summary: Text is missing from the intro.

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.

Possible decisions:

1. Yep sure fix it

Decision: 1/ fix it

[XL100] Editorial: Various

Source: Susan Lesch http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0012.html

Summary: Various copy edits.

After clause 1 par. 3, "these characteristics:", the characteristics 
seem to be missing.

In 2.3 par. 2, "the the" -> "then the"

In the illustrations extended-ool.gif, extended-inl.gif, 
extended-arcs.gif, and simple.gif (in clauses 5.1, 5.1.3, and 5.2), 
it might help if "loc" and "rsrc" were spelled out.

Also, the GIFs are black on transparent which in rare cases can be 
invisible. Black on a white background would match the W3C style 
sheet and still be legible for people who have a user style sheet set 
to light text on a dark background.

In the example in 5.1, unless they are acronyms understood 
internationally, I would spell out "teaching assistants", and spell 
out "Grade Point Average" near the first time GPA is used.

In 5.1.5, in the paragraph between the example tables, "that serve as 
starting resource" -> "that serve as starting resources" or, "that 
serve as a starting resource"

In 5.4 par. 3, "crosshatch (#) and percent sign (%) characters." -> 
"number sign (#) and percent sign (%)." (See 
http://charts.unicode.org/PDF/U0000.pdf. Thanks to Martin Duerst for 
pointing this out in XML Base.)

In A.1., the RFC 2396 URI could be IETF's at 
http://www.ietf.org/rfc/rfc2396.txt

Possible decisions:

1. Yes sure apply changes

Decision:

[XL102] Editorial: Fix example in Section 5.2

Source: David Olson http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0018.html

Summary: looks like an omission

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.

Possible decisions:

1. sure fix it

Decision: 1/ fix it

[XL103] Editorial: Use "crosshatch"

Source: Jonathan Marsh http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0028.html

Summary: minor I18N comment to change 'crosshatch' to 'number sign' (the official name of #).

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.

Possible decisions:

1. Sure change it

Decision: 1/ fix it

[XL104] Fold arcrole attribute into role attribute

Source: Elliotte Rusty Harold http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0030.html

Summary: making XLink simpler by deleting arcrole and allowing role attributes on arc elements.

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

Eve provided the rationale and we're unlikely to change, but he did make a proposal and so we should respond formally.

Possible decisions:

1. agree with the change
2. keep as is

Decision: 2/ Keep as is, with the already-stated rationale by Eve.

[XL105] Lose the title-type elements

Source: Elliotte Rusty Harold http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0031.html

Summary: really not sure they're necessary or useful in practice

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

Possible decisions:

1. Remove title elements.
2. Remove title elements and attributes.
3. Get specific about using xml:lang.
4. Status quo

Decision: 4/ to keep the status quo. No consensus for #1 or #2. We discussed #3. Some would be interested in getting more specific, but others didn't want to limit to I18N purposes. This is just another providing link metadata; we don't tell people how to use roles either.

[XL106] Change the name of the resource-type element

Source: Elliotte Rusty Harold http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0051.html

Summary: 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.

See also David Orchard's and John Simpson's responses.

Possible decisions:

1. Change "resource" to "local"
2. Change "resource" to "local" and "locator" to "remote".
3. Change "resource" to "here" and "locator" to "uri".
4. Some other set of changes.
5. keep as is

Decision: 5/ keep as is. No consensus to reopen; it's too late and the changes didn't garner a lot of support. This is something of a taste issue.

[XL107] Editorial: arcrole is allowed on simple links too

Source: Toivo Lainevool http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0113.html

Summary: 5.5 misses the fact that the simple-type elements may also have an arcrole attribute.

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.

Possible decisions:

1. Sure, fix it

Decision: 1/ fix it

[XL108] Editorial: RFC 2732 reference

Source: Martin J. Duerst

Summary: xLink misses an RFC 2732 reference.

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?

XPointer does indeed already contain a reference.

Possible decisions:

1. Sure, fix it

Decision: 1/ fix it

[XL109] Editorial: arcrole and title allowed on arcs too

Source: Christopher Ferris by way of Eve Maler

Summary: The arcrole and title attributes may be used on arc-type elements.

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.

Possible decisions:

1. Sure, fix it

Decision: 1/ fix it

[XL110] Container locations vs. container nodes

Source: Matthew Wilson http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000OctDec/0029.html

Summary: "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?)

Eve says: I believe that we just want to change "container location" to “container node" here, but I wanted to confirm this. If x is not a range location, then does this always imply that x has to be a node?

Options:

1. Change "container location" to “container node"
2. Define the notion of a "container location" and integrate it into the definition of point
3. Do something else
4. Keep as is

Decision: 1/ Change container location to container node in 5.4.3

[XL111] Request for non-normative DTD with "XLink semantics"

Source: Murray Altheim http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000OctDec/0047.html

Summary: asking for a DTD defining XLink

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.

Eve says: Several people have asked for "a DTD," but this description finally makes me realize how such a DTD could be provided with some useful level of precision. I'd be in favor of this, and in fact have created a draft DTD for discussion. Note in particular the assumptions that accompany the DTD.

Options:

1. Add a non-normative DTD
2. Keep the spec as is

Decision: 1/ adding a non-normative DTD based on Eve's one with simple links added

[XPR1] Accessing the XML declaration

Source: XPointer Requirements document

Summary: section A.2 says:

---

• For any single element, character in content, or PI in an XML document, it must be possible to create at least one XPointer that specifically identifies it.

  This includes special processing instructions such as the XML declaration and the stylesheet-attachment PI.

---

We do not provide any special access to the XML declaration (I think the stylesheet PI can be accessed via the usual XPath PI mechanisms). I believe this is because DOM and/or the InfoSet don't either. XPath provides no way to get this node, since it does not count properly as a processing instruction

We can delete the requirement, or add a special function to access this node. The ugly part is that since it is not formally a PI, it does not fit any of the existing node types, so we'd have to add a new node type for it, which is non-trivial.

I think our best response is to add a note indicating that it cannot be accessed at this time, and delete the requirement or reduce it to 'should' or 'may'.

Possible decisions:

1. delete the requirement
2. add a special function to access this node
3. add a note indicating that it cannot be accessed at this time

Resolution: Change the requirement to "should"

[XPR2] Testing datatype-specific conditions

Source: XPointer Requirements document

Summary: section B.7 says:

---

• The XPointer specification should make clear a way that it can be extended to support testing datatype-specific conditions when XML Datatypes are later available through the work of the XML Schemas Working Group.

  For example, once it is possible to know which attributes or content strings constitute integers, date, or real numbers, it should be clear how to extend the language to accommodate appropriate comparisons within its conditional constructs.

---

This one we simply haven't touched. XPath has a non-interoperable way to do this, namely extension functions; but we don't allow them (which has the advantage of greater interoperability....).

This one is already a 'should' rather than a 'must' in the requirements; I think we knew it was a stretch from the beginning. At most, I recommend we add a note indicating that there is no way to do type-specific tests on datatypes other than those already defined, and that future versions of XPointer may provide this based on the ongoing XML Schema work.

Possible decisions:

1. Drop from requirements
2. Change to 'should' in requirements
3. add a note and postpone to next version

Resolution: Keep as is (acting as a reminder to examine selecting on types once XML Schemas is a REC)

[XPR3] Specifying the version of a target resource

Source: XPointer Requirements document

Summary: section B.8 says:

---

• The XPointer specification must provide a way to specify what version of a target resource is intended to be identified.

---

We basically decided this is the main URI's problem, not the fragment identifier's. So we should delete this requirement. We may wish to also add a note to the spec referring to WebDAV for work on version management, and add them as a non-normative reference.

Possible decisions:

1. Drop from requirements
2. Change to 'should' in requirements
3. add a note and point to WebDav

Resolution: Keeping it (and done as a property of the URI), add a non-normative reference to WebDAV

[XPR4] Checking the resource content

Source: XPointer Requirements document

Summary: section C.1 says:

---

• It must be possible, but not mandatory, to create XPointers that can be tested for whether they identify "the same" target when followed as they did when created.

  For example, this may be accomplished by providing a checksum of the destination data. This massively improves robustness because you can detect when a link has broken (although it cannot prevent link breakage from ever happening). [There is not consensus on whether this requirement should be addressed within XPointer or XLink].

---

The final [ ] saves us here, since we decided this belongs in XLink rather than XPointer. Sadly, we failed to address it there. This seems to have fallen between the cracks between XPointer and XLink.

I think we really should fix this, in XLink. The easiest way is to provide an optional attribute on locators, that takes a scheme prefix that identifies the checksum or signature method in use (we could predefine at least one, MD5 being the obvious candidate based on earlier reviews), and then gives the value. This is easy, optional for users, and I think it's worth doing. The Canonical XML effort is aimed to provide precisely the string one wants to checksum, so we can reference that, although still non-normatively since it isn't a REC.

Possible decisions:

1. Drop from requirements
2. Point to XLink (and add it to XLink)
3. Point to XLink but postpone it to later version of XLink

Resolution: it's an XLink requirement, move it in XLink requirement

[XP1] Tumblers

Draft currently posits that tumblers may be added to XPath. That seems very unlikely now.

Options:

1. Specify the mapping of the current grammar to XPath.
2. Specify XPointer-specific integration of tumblers with full XPath functionality.

   It would be nice if a location spec could start with a tumbler but then use predicates and the full capabilities of XPath. But this will take time to define because of potential ambiguity in the grammar.

3. Remove tumbler functionality from XPointer spec.

Resolution:

Keeep it as if!

[XP2] URI escaping

Need to describe escaping rules for when %encoding is needed and when it is not.

This issue is believed settled, and we merely need to craft the prose for it.

Resolution:

@@

[XP3] Multiple location specs - necessity and processing model

Resolution:

Keep multiple location as explained in the current version of the specification

Keep the processing model as explained in the current version of the specification

[XP3.1] Multiple location specs - necessity

The Xpointer syntax provides a scheme and scheme-specific-string model in its top-level production. The WG had not reached consensus on the need for this functionality, nor on the use of an explicit termination character (i.e. ')'). On the other hand, we have had feedback from Philipp Hoschka that this is important functionality for SMIL.

Options:

1. Do nothing - spec is OK as-is
2. Remove this functionality
3. Further define this functionality - escaping rules, etc.

[XP3.2] Multiple location specs - processing model

The XPointer spec currently evaluates multiple pointers using a 'short-circuit OR' semantic. In other words, try the first, second, ... Location specs until one of them succeeds. Don't report any errors unless all of the fail. It has been pointed out that there may be other useful ways of combining the location terms. Boolean combinations are one possibility.

Options:

1. Do nothing - spec is OK as-is
2. Remove capability for multiple location specs (this might arise as a result of [XP3.1]).
3. Define combining operations.

[XP4] checksums made XLink issue, not XPointer issue

Believe this is not really an issue, and all we have to do is decide if the XPointer spec says "we used to think XPointer would provide this but now we think it is a problem for XLink".

Resolution:

@@

[XP5] problems with use of '//' in URLs

Members of the WG have reported that some HTTP servers do bad things when they are given URLs which contain '//' in the fragement. However, that syntax is used in XPath. The subgroup considered this and decided to go ahead with using the '//' as we heard from an employee of the company making one of the offending servers that it was OK to do so.

Options:

1. Continue with that decision.
2. Change XPath to not use '//'.

Resolution:

consensus:1/ This is a bug on the server.

[XP6] use of 'parent' to denote element containing an attribute

The question is - given an attribute node, how to get to the element bearing that attribute? The XSL WG debated this and decided that the parent axis woud be used. This has the unfortunate property of meaning that while an attribute may have a parent, the attribute is not a child of the parent. The XSL WG is aware of this but does not consider it to be a significant problem. The alternative they rejected was the introduction of another axis.

Options:

1. Stick with that decision and leave the spec alone.
2. Attempt to get the XSL WG to reverse their decision, then modify XPath.

Resolution:

consensus on 1/, we already discussed (voted ?) that issue, This may be revisited when reviewing DOM feedback.

[XP7] namespace initialization

The namespace context must be initialized before comparisions on qualified element types can be made. The spec is currently inadequate in this area.

Resolution:

Dropped, we can do it, already, the syntax will be provided in the Xpointer specification

[XP8] will XPath take up the string() axis/function?

One part of this issue is covered under XP12, deciding if the string and range axes should be functions instead. A second part is to see if:

1. We should retain the full functionality of the string axis
2. We should have equivalent functionality moved into XPath.
3. We should sacrifice some of the functionality and use only the XPath functions such as substring(), substring-before(), and substring-after().

Resolution:

Consensus: it's impossible to add string() to XPath now

Consensus: on keeping string() functionnality

Pending: rewording of that part, to be discussed

Consensus: closing it, the draft defines string-range(), it's not in XPath that's an extension (James proposal)

[XP9] case-insensitive string comparison

The I18N WG has urged us to say that string comparisons are peformed on the binary content of the string. At the same time, case insensitive searching is a useful feature for users of languages that have the notion of case.

Options:

1. Use the XPath translate() function to provide case insensitive searching.
2. Not allow case-insensitive searching at this time.
3. Something else.

Resolution:

1) reuse the XPath translate()

[XP10] access to internal structure of DTD, XML declaration

Right now we can't locate content in DTDs, nor can we access the pseudo-attributes in the XML declaration.

Options:

1. Do nothing - the spec is OK as-is.
2. Add these capabilities in XPointer
3. Add these capabilities and try to get them into XPath.

Resolution:

Consensus: In version 1.0 there won't be a mechanism to point into DTDs or Schemas

[XP11] membership lists and affiliations

This is an editorial point - getting the current lists correct, dealing with former members, etc.

Options:

1. Spec is substantively OK, just make a new section for former WG members.
2. Don't list WG members.
3. Something else.

These issue have been raised on the mailing list:

Resolution:

Consensus: Everybody part of the WG at release time is entlitled to be listed, check back with the editor

[XP12] Should string and range axes be functions?

Right now, these are considered 'axes', but they have differences from the other axes defined in XPath. At the same time,

Resolution:

Same as [XP8]

[XP13] Addressing an XSLT result tree

Should we provide a fragment scheme or a result() function to address nodes in an XSLT result tree? If not, how are generated elements addressed?

Options:

1. Add a result() function or equivalent to XPointer.
2. Add a result() function equivalent to XLink.
3. State that the use of XPointers in XSL applications is undefined and that their definition is not our job.

Resolution:

dropped, to be added in future versions

[XP13.1] What is the URL of a result tree?

Related to XP13 is the question of identifying a result tree so that XPointers can be used to address into them.

Options:

1. State that the definition of result tree URLs is not our job.
2. something else ???

Resolution:

dropped, to be added in future versions

[XP14] unique() returns boolean

Currently unique() returns a boolean, meaning that it can only appear within a predicate in an XPointer. For instance, it appears that #xptr(unique(a/b/c)) is invalid.

Options:

1. Redefine unique() to return a nodeset as follows - if the nodeset contains a single node, return that nodeset, otherwise return the empty nodeset. The XPath conversion from nodeset to boolean within a predicate will allow this to continue to work within predicates. When used outside the predicate, attempting to return an empty nodeset correctly generates a sub-resource error.
2. Remove the unique() function.
3. Do nothing. Current limitations are acceptable.

Resolution:

[XP15] Provision for XML Schema datatypes

Requirement B7 in the updated XPointer requirements draft says:

The XPointer specification should make clear a way that it can be extended to support testing datatype-specific conditions when XML Datatypes are later available through the work of the XML Schemas Working Group.

This requirement is believed not to be met.

Options:

1. Delete the requirement.
2. Add such functionality to the spec.

Resolution:

XPointer can be extended, we don't have a specific syntax right now.

Consensus on not handling it in V1.0, we can't meet it because Schema is not ready yet, suggestion to postpone it to a later version.

[XP16] Reuse of XPointers in other XPointers

Requirement D2 in the updated XPointer requirements draft says:

The XPointer specification must provide for re-use of XPointers by other XPointers. [There is not consensus that this is a short-term requirement, though there is consensus on its desirability in principle.]

This requirement is believed not to be met.

Options:

1. Delete the requirement.
2. Add such functionality to the spec.

Resolution:

Consensus that this requirement will not be met for the 1.0 release

[XP 21] Restrict eval context only to defined functions

Problem of interoperability, can we restrict to existing defined functions, basically refusing extension of XPointer and (current) XPath core function:

Consensus:

Agreed, by leaving as-is the XPointer draft refusing function extensions

[XP22] Position data type vs. use of collapsed ranges

James' original suggestion did not have a position data type. Instead, when a single position was needed a 'collapsed range' was used. The disadvantage of the new datatype is that more types means more possibility for type errors. The advantage of it is that conceptually distinct things have distinct types, so type errors serve as diagnostics for logic errors.

Options:

1. Keep the separate datatype
2. Use collapsed ranges

(Editor's recommendation is to keep the distinct datatype for position (or point or whatever it gets called) vs. range. Also, where the draft currently says it does not constrain actual implementation, it could go on to point out that positions might be implemented in terms of ranges that have the same starting and ending positions.)

Resolution: use a position datatype

[XP23] New term for position

Draft uses 'position' when talking about range end-points. This is in conflict with XPath use of the term for position within a node-set result. (Note that the DOM uses position, so whatever we decide we should suggest they adopt as well.)

Options:

1. Go back to original suggestion of "end-point". This has the disadvantage of the beginning of a range being called the "starting end-point", a rather tortured construction.
2. Call it a "point". The ends of a range could then be called the "starting point" and "ending point". The advantage of this is its brevity. Its disadvantage is its brevity - there may be other things called 'point' that we are not aware of.
3. Call it 'boundary-point'. Disadvantages are length, and the frequent misspelling of boundary.
4. Change XPath usage of position so that DOM does not have to change. (This option seems unlikely, but its probably worth listing.)
5. Something else?

(The editors have no strong opinions on this issue, but do agree that the name must be changed. "point" has slightly greater favor.)

Resolution: use the single term "point".

[XP24] return type of starting-position() and ending-position()

James Clark notes that the return types should be location-set, not single positions, for better integration with XPath.

(Editors' recommendation is to make this change).

Resolution: editors to do the change

[XP25] Overlap of starting-position() and ending-position with range-before() and range-after()

If the return type of starting-position() and ending-position is changed, they are equivalent to the range-before() and range-after() functions.

(Editors suggest that the names of the functions should be chosen based on earlier decisions about position vs. range data type, and name for position datatype.)

Resolution: editors to do the change

[XP26] container-node() overlaps with ..

James Clark notes that XPath provides the ".." construct, which is the general purpose equivalent of the special-purpose container-node() function.

(Editors suggest we scrap the container-node) function and describe XPointer extensions to "..", namely, that we define the parent of positions and ranges. This will also have the benefit of clarifying how one manages the point at the end of a range. Currently, for example, the ancestor axis when applied to a range, has the same results as ancestor for the first node *in* the range; which while often good enough, is not the same thing. This makes it awkward or worse to address relative to the end of a range. The point immediately preceding a chapter is not, properly speaking, the same as the start of the chapter, and the range/node/point distinction reflects this distinction transparently. )

Resolution: editors are directed to proceeed with suggested changes, i.e. removing container-node() .

[XP27]"Node" terminology

Main issue here is imprecision on XPath's use of the term "node", and the Information Set's non-use of the term.

Options:

1. Try again
2. Leave it.

(Editors suggest trying again.)

Resolution: Leave it

[XP28]Relational operators for positions and ranges

Issue here is that XPath already defines the relational operators to operate on the string value of locations. Changing those to operate on the document order would be difficult, if not impossible, and would surprise many users of XPointers if it were possible.

Options:

1. Drop relational comparisons of positions and ranges.
2. Provide new function, such as cmp-order(location-set, location-set), that returns -1, 0, 1, depending on the relative order of the two locations. (That function will also have to have a return value that means 'undefined', for cases such as comparing the order of two attributes.)

(Editors recommend defining the new function. This provides additional incentive for keeping points distinct from ranges, since the meaning of order comparison for the two is not identical. by keeping them separate, we can avoid complex comparison semantics.)

Resolution:

Dropped

[XP29] string-range() prototype needs question marks

The string-range() function prototype needs question marks after the optional arguments.

(The formatting software has been updated to fix this problem.)

[XP30] Assorted definitions about positions

The position data type does not have definitions for its string-value, expanded-name, etc. Those should be defined. James Clark has provided suggested definitions. They update the last three paragraphs before 4.3.1. The suggestions are:

In the paragraph about the string-value of a range location, say that the string-value of the position location is empty. In the paragraph about the expanded-name of a range location, say that a position location does not have an expanded name. In the paragraph about axes, change it to this:

The axes of a position location are defined as follows. A position location has no children. If the position is a character-position, then the position location has no preceding siblings and no following siblings. If the position location is a node-position, the preceding or following siblings are the children of the container node that are before or after the node-position. The axes of a range location are the axes of its starting position.

Options:

1. Adopt the suggestions
2. Tweak the suggestions
3. Something else

(Editors recommend that the suggestions be tweaked. In particular, we think the distinction between node-position and character-position should be (re)considered by the WG.)

Resolution: adopt James Clark suggestion

[XP31] Tumblers start from document element, XPaths start from document root

Copying from Jonathan's email...

The XPointer WD states: "Second, a shorthand that locates an element by stepwise navigation from the document element, using a sequence of '/'-delimited integers. Each integer locates the Nth child element of the previously located element, where N is the value of the integer."

There is potential confusion between the notation of tumblers and that of XPath, in that "/" in XPath represents the document root, while in tumblers, "/1" represents not the first child of the document root (the document element), but the first child of the document element. In short the tumbler "/1" and the XPath "/*" are not equivalent.

For instance:
     /1 == xptr(/*/*[1])
     /2/2 == xptr(/*/*[2]/*[2])


Conversely, this means that there is no tumbler that can be used to access the document element, namely:
     xptr(/*)
has no tumbler equivalent (but at least it's not equivalent to "/" :-)

It occurs to me that it might be useful to combine tumblers and bare names, to allow:
     #foo/1 -- first child of the element with id foo
but perhaps this is too much to consider at this point (although it is not a large functional or syntactic change).

Options:

1. Define tumblers to operate off the document root, e.g. /1 is the document element. /1/1 is the first child of the document element, etc.
2. 1 + allow tumblers to be appended to bare names.
3. Document the relationship between tumbler notation and XPath notation with some examples showing that "/1" and "/*" are not equivalent.
4. Get rid of tumblers altogether (hey, it's draconian, but should still be considered as a solution).
5. Leave things as they are.
6. Use special syntax, such as "!", at the start to avoid the need for always saying "/1".

(The editors don't have a consensus recommendation, although both like option 2. Opinion is divided on option 6. )

Resolution:

On using option #2

[XP32] Syntax errors in examples

Syntax errors have been noted in the examples from section 3.2.

(Editors apologize. The suggested corrections have been made.)

[XP33] No ^-escaping in BNF

Copying from Jonathan's email...

While not a native BNF speaker, the BNF in section 3 doesn't seem to handle the "^" escaping mechanism for the xptr scheme. Is this because it is not possible with BNF notation? If so, does this need to be called out with an explicit "validity constraint"?

Right now, the explicit validity constraint is: "Validity Constraint: When the Scheme is 'xptr', the SchemeSpecificExpr must match the production for XPointerExpr." Isn't this redundant with the BNF?

Options:

1. Change the BNF to more accurately reflect the escaping mechanism.
2. Update the Validity Constraint to reflect the escaping mechanism.
3. Do nothing because this issue is nonsense :-).
4. Do nothing because it isn't important.

(The editors would like to reassure Jonathan that this is not nonsense :-). However, escaping rules like the use of ^ are difficult to express in BNF. We can certainly attempt to clarify the two validity constraints.)

Resolution: Editors are allowed to "tweak" the EBNF

[XP34] No tumbler errors defined

No errors, such as raising a sub-resource error if a tumbler locates a non-existent element, are defined for tumblers.

Options:

1. Explicitly define tumbler errors
2. Define the mapping from tumbler expressions to XPath equivalents and state that errors are handled as specified by the equivalents.
3. something else

(Editors agree that these errors need specification in some manner. These appear to be precisely the same as the already defined errors for full-form XPointers, so tweaking the language to clarify that those error definitions apply to xpointers, bare names, and tumblers should suffice.)

Resolution:

tweak definition to apply XPath standard errors to tumblers and bare names

[XP35] escaping unclear

Source: I18N feedback http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0036.html,

Summary: Lack of detail of what, whan and where part of XPointer expressions have to be escaped. This affects section 2.2 and section 2.1. the I18N mail is fairly detailed

Possible decisions:

1. Drop this this is clear enough
2. Ask the editors to revamp this section, and provide examples

Resolution:

2/ the editors are asked to clarify this section, possibly by reusing some wording from the original mail

[XP36] ^escaping is not needed () escaping

Source: I18N feedback http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0036.html

Summary: The URI spec all (), so they don't need to be escaped it is then possible to use %28 and %29 for ( and ) escaping within XPointer expressions, however there might be possible drawback

Possible decisions:

1. Keep the current ^ based escaping mandatory
2. Relax it and suggest %28 and %29
3. drop it and force people using %28 and %29

Resolution: (with better statement from Ron)

The WG was not able to convince itself that the ^ escaping was not necessary, and at a minimum we would have to specify the rules around escaping of parentheses in more detail. Therefore the group decided to leave the spec as-is.

[XP37] XPointer/DOM differences in char counting

Source: I18N feedback http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0036.html

Summary: Points and Ranges correspond, to DOM's "position" and "range". However, DOM's position and range are based on UTF-16 units while XPointer on the other hand works on UCS characters

Possible decisions:

1. Add a note on this issue

Resolution:

Add a note on this issue

[XP38] child sequences are unstable

Source: I18N feedback http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0036.html

Summary: addressing by child sequences as described in 2.1.3 is especially unstable in case of editing or translation

Possible decisions:

1. Remove it
2. Keep it
3. Keep it and add a not on this matter

Resolution:

2/ keep as is. All XPointer constructs are potentially unstables w.r.t. editing

[XP39] matching and normalization

Source: I18N feedback http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0036.html

Summary: There should be some comment about matching and normalization in 3.5. The review suggest some wording.

Possible decisions:

1. Add a comment on this
2. drop it this is orthogonal to XPointer

Resolution:

1/ add a comment on this

[XP40] Whitespace handling in 'string-range'

Source: I18N feedback http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0036.html

Summary: This is defined so that multiple spaces in the source match with multiple spaces in the XPointer. In as far as this is used to deal with 'pretty printing' in the source or in XPointers (as opposed to catching spurious double spaces,...), this is inappropriate because it does not cover languages that are written without spaces, such as Thai, Chinese, and Japanese. This has to be improved.

Possible decisions:

1. ???

Resolution:

Paul grosso sent a very clear mail on the subject and suggesting 4 possible actions. The editors are instructed to remove the section on normalization, add note how XML processors have to normalize end of line characters.

[XP41] [ and ] are used for IPv6 adresses

Source: Larry Masinter http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0000.html

Summary: What's raised the issue is a proposal (as a result of work in representing IPv6 addresses in URLs) to move the characters "[]" into the reserved set.

Possible decisions:

1. drop it (issue a liaison to the IETF group ?)
2. remap to something else (what ???)

Resolution:

keep use of [] they are actually used in XPath. if this need to be escaped leave it to W3C and IETF to decide.

[XP42] subset XPointer?

Source: SYMM WG review http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0029.html

Summary: Is it legal to subset XPointer? At what level of granularity? Should we do it with a subset without ranges ?

Possible decisions:

1. No that's illegal
2. Yes using a different scheme
3. Yes we are providing such a scheme

Resolution:

All conformant XPointer processors must process the entire spec 1/

[XP43] drop ranges

Source: XSL WGhttp://lists.w3.org/Archives/Member/w3c-xml-linking-wg/1999Dec/0074.html, Paul Grosso http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0010.html, Oracle http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0044.html, Rick JELLIFFEhttp://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0046.html, Jonathan Marshhttp://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0041.html

Summary: Various point of view

• complicate the language, fragment identifier support has to be added to lot of software which will have to support it
• ranges could be expressed as 2 XPointers
• this doesn't answer the need to map user selection due to XSL transformation
• existing specifications do not use it (namely XSLT and XInclude)

Possible decisions:

1. Keep them
2. Provide a separate scheme without ranges
3. Drop them

Resolution: effective consensus on keeping them, a minority opinion report was drafted by Paul Grosso

[XP44] interaction with XSLT

Source: XSL WGhttp://lists.w3.org/Archives/Member/w3c-xml-linking-wg/1999Dec/0074.html, Oracle http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0044.html

Summary: mapping back an XPointer (or a selection) to the source document when the rendering has been generated by an XSL(T) transformation

Possible decisions:

1. out of scope
2. ???

Resolution:

XPointer addresses within a given Infoset. XPointer has no notion of input or result set. This issue is out of scope for the XPointer specification.

[XP45] Range and character definition

Source: Oracle http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0044.html

Summary: Ranges implies defining what is a selection and the resulting character set, DOM opted to 16bits chars, this is not defined in XPointer. Related to [XP37]

Possible decisions:

1. This is defined in XPath and inherited, use UCS, add a note
2. ???

Resolution:

1/ this is defined in XPath (c.f XPath REC Introduction "string (a sequence of UCS characters)") and we are using UCS and already voted on this

[XP46] Multiple Ranges/Node/Points

Source: TimBL, private discussion with staff contact, Paul Grossohttp://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0010.html

Summary: XPath allow returning multiple values, and XPointer don't constraint it allowing to return multiple (non consecutive) nodes, or multiple points/ranges. This complicate handling and may be hard to get implemented and linked to UI. Note that the I18N WG considered that a good feature.

Possible decisions:

1. keep them
2. allocate a new scheme ???
3. Force XPointer to return a single value ???

Resolution: this was discussed already the WG considered that a feature, keeping it. @@@pointer

[XP47] how schemes are managed?

Source: Martin Duersthttp://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0037.html

Summary: who allocate scheme names to avoid conflicts ? This is a repository and W3C is not inclined maintaining repositories. This is a serious problem.

Possible decisions:

1. this is intimely related to the mime type of the resource and this should be managed at the same level. (may imply liaison with IANA)
2. map them to URI, or namespace ???
3. ???

Resolution:

The WG recognize the risk of collision, the WG cannot provide the mechanism to prevent this. Checking the errata in the future is the place where to look for a possible solution.

[XP48] Whitespace between schemes

Source: Jonathan Marsh http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0008.html

Summary: we should allow "#xpointer(...) xpointer(...)" as whitespaces are allowed between the parens

Possible decisions:

1. add this to the BNF
2. drop it

Resolution:

1/ allow them and note that this will have to be escaped when embedded in an URI

[XP49] Integration of namespace

Source: Martin Duersthttp://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0037.html

Summary: The scheme is too complicated, suggest uri-name()='http://www.foo.com/bar:y'

Possible decisions:

1. Add the suggested shortcut
2. this is inherited from XPath keep as is

Resolution:

[XP50] XPointer need null()

Source: Jonathan Marshhttp://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0040.html

Summary: Many database constructs leverage the concept of a null pointer. XPointer does not have this capability.

Possible decisions:

1. drop it
2. Introduce a new fragment scheme which accepts no arguments: i.e. #null()

Resolution:

1/ The WG don't really see a need right now and could be added later as a new fragment scheme

[XP51] character-point/node-point definition

Source: Robert Hanson by way of Eve Malerhttp://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0003.html

Summary: if a node-point is "When the container node of a point is of a node type that can have child nodes", and a character-point is "When the container node of a point is of a node type that cannot have child nodes", then what about characters in a node that CAN have child nodes? It seems that by definition that this is not defined.

Possible decisions:

1. Update the definitions
2. This is correctly defined keep as is (add note ?)

Resolution:

In the disposition of comment explain that nodes are not elements (text nodes vs. element nodes) hence that case cannot happen

[XP52] does root() still exist

Source: Elliotte Rusty http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0004.html

Summary: Does the root() function still exists as the Dec. 6 working draft of XPointer? It's mentioned twice in the draft but only in passing, and it's not mentioned at all in the XPath 1.0 spec.

Possible decisions:

1. Add it to XPointer
2. Remove references from XPointer

Resolution:

Good catch. root() doesn't exist anymore, editors are directed to replace root() by reference to "/" construct

[XP53] erratas

Source: Martin Duersthttp://lists.w3.org/Archives/Public/www-xml-linking-comments/1999OctDec/0037.html

Summary: Please make sure the final Recommendation will have a pointer to errata.

Possible decisions:

1. yes sure

Resolution:

yes will be done when going to REC

[XP54] Range syntax

Source: DV http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Jan/0011.html

Summary: the current range syntax based on " to " need modification to the XPath parser, thsi need to be changed. Steven proposed a function based syntax and checked with James Clark.

Possible decisions:

1. Keep as is
2. adopt the new syntax

Resolution:

Use rangeto function instead of the ... to .. construct

[XP55] "character sets" vs. "character encodings"

Source: Martin Duërst on behalf of the Internationalization Working Group, raised the following issue about character sets and escaping, in section 2.2 of the XPointer Working Draft.

Summary: The title should be changed from "character sets" to "character encodings"

Possible decisions:

1. Change it
2. Keep old termonology
3. find another one

Resolution: 1/ Change it accordingly to Martin comment

[XP56] UTF-8 encoding is not necessary for URI-references

Source: Martin Duërst on behalf of the Internationalization Working Group, raised the following issue about character sets and escaping, in section 2.2 of the XPointer Working Draft.

Summary: Martin believes that we should clarify that the UTF-8 encoding is not necessary for URI-references, but rather, for XPointer itself.

Possible decisions:

1. yes draft a note about it
2. no keep as is

Resolution: 1/ Change it accordingly to Martin comment but substitute URI references by XPointer

[XP57] clarify certain distinctions about illegal characters in URI-references

Source: Martin Duërst on behalf of the Internationalization Working Group, raised the following issue about character sets and escaping, in section 2.2 of the XPointer Working Draft.

Summary: Martin believes that the specification should clarify certain distinctions about illegal characters in URI-references

Possible decisions:

1. yes inc note about this
2. no keep as is

Resolution: Removing that note. Eve will write a rationale about illegal URI char support and send to group for inclusion in DOC

[XP58] validity constraint about not all legal XPath expressions may be used when escaping.

Source: Martin Duërst on behalf of the Internationalization Working Group, raised the following issue about character sets and escaping, in section 2.2 of the XPointer Working Draft.

Summary: Martin believes that the second validity constraint in this section is unnecessary. This validity constraint declares that not all legal XPath expressions may be used when escaping.

Possible decisions:

1. change it
2. keep as is

Resolution: Editors to do the changes requested

[XP59] directly reference the Unicode and UTF-8 specifications

Source: Martin Duërst on behalf of the Internationalization Working Group, raised the following issue about character sets and escaping, in section 2.2 of the XPointer Working Draft.

Summary: Martin believes that this section must directly reference the Unicode and UTF-8 specifications. Resolution: The editors should add the references to Unicode 3.0 and RFC 2379, respectively.

Possible decisions:

1. yes add those links in the appendix
2. no (why ???)

Resolution: 1/ The editors should add the references to Unicode and RFC 2379, respectively. However XML-1.0 uses Unicode 2.0 while future version may use 3.0. Martin will be contacted to find how to handle this.

[XP60] I18N be a requirement in implementing XPointer.

Source: Martin Duërst on behalf of the Internationalization Working Group raised the following issue about the introduction of the XPointer Working Draft:

Summary: In regards to robustness requirements 'must attempt to be internationalized' apparently isn't strong enough for the Internationalization Working Group. They would like the Working Group to state that internationalization is a requirement in implementing XPointer.

Possible decisions:

1. yes add sucha note
2. no the I18N support is fully covered by XML/Infoset/XPath specs

Resolution: This is an (unecessary) rewrite of the requirement, just remove it since we reference it. This section will be removed

[XP61] preceding relative axes error

Source: Michael Dyck raises the issue that, in section B.3 :

Summary: we declare that the preceding relative axes: Locates nodes that begin before (preceding) the entire context node. The list is in reverse document order: the node closest to the context node first, root() last. Ancestors are included. This is in direct conflict with XPath, which states that explicitly excludes ancestors from the preceding axis.

Possible decisions:

1. right this need to be fixed
2. no keep as is

Resolution: Yes this is an error drop that subpart of the sentence and keep the compatibility with XPath

[XP62] the definition of a node is in conflict with the Infoset

Source: Martin Duërst notes that, in the definition of a node:

Summary: we are in conflict with the Infoset, which does not include the concept of text nodes. The DOM does define text nodes, however.

Possible decisions:

1. Since XPointer was aimed at compliance with the DOM more than with the Infoset, we should strip references to the Infoset from the definition of a text node, and instead refer to the DOM. We should do the same for the section of the specification discussing CDATA sections.
2. Stricty follow Infoset on this issue and change the node definition
3. other ???

Resolution: we are really basing our work on xpath view. We use text nodes as defined in XPath.

[XP63] Axis usage error

Source: Martin Duërst notes that, in section B.6,

Summary: the following text is inaccurate: Perhaps the most important of these allows the axis identifier and parentheses to be omitted from a Step.

Possible decisions:

1. keep as is
2. change wording. Ben suggests: Perhaps the most important of these allows the axis-name and double-colon to be omitted from a Step. This change should, preferably, reference the axis-name production.

Resolution: Instead of mentionning the parenthesis, mention the axis identifier and reference the XPath axis production specifically.

[XP64]

Source: The following was an ednote from sjd, at the end of the Evaluation Context Initialization section:

Summary: While the idiom mentioned above alleviates the need for additional namespace initialization mechanisms, XPointers using it can become quite long - potentially exceeding the practical limits on URI length established by many applications. An alternative proposal is to augment the XPointer grammar to allow namespace prefixes to be initialized then used in the XPointer. The proposed grammar would change GeneralFragmentPart to:

GeneralFragmentPart ::= 'xpointer' '(' NSInit* XPointerExpr ')'
NSInit ::= 'xmlns:' prefix '="' URI '";'

It would also require occurrences of the semicolon character ';' to be escaped by the circumflex '^' character. Note that this is only an issue for occurances of XPointers in non-XML documents. However, there are use cases such as copying an XPointer from an XML document and pasting it into an email message where such an initialization mechanism would be useful. Feedback on the desirability of this addition to the specification is requested.

Possible decisions:

1. Eve response: This is a good idea, but I would wait for V1.+ before putting it in. Let's hang onto the idea in this form and in the issues list for now.
2. Jonathan response: My recollection is that we have decided this, and it is inappropriate to have this kind of statement in a last call. Remove the note.

Resolution: referenced in issue list but not added to draft.

[XP65] XPointer to resources without Infoset

Source: Paul Grosso for the XML Core WG http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0049.html

Summary: Some documents may be delivered as XML but not have Infosets

• XML 1.0 well formed documents that do not have infosets, such as those that contain names with colons that are not namespace-conformant.
• Possibly XML external parsed entities resources. Are they of Mime Type XML ?

Those documents may be considered of Mime Type XML, but since they don't have Infoset (or rather an XPath "data model") it seems one cannot use XPointer for those resources.

The mail present 2 well formed external parsed entities but without a single root element, and ask for clarification about using XPointer if this is allowed.

Possible decisions:

1. Only documents with Infoset (or XPath "data model") can be used with XPointer, the Abstract of XPointer should be updated.
2. All Well Formed documents should be processable by XPointer (this may require a modification of XPath), even if they violate the XML Namespace REC.

Resolution: 1/ XPointer applies only to document for which an Infoset or an XPath data model can be built

[XP66] ChildSeq and Well balanced XML chunks support

Source: Michael Kay http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0039.html about the XPointer CR version

Summary: The syntax of ChildSeq suggests that XPointer is constrained to operate on well-formed XML documents (those with a single top-level element), in contrast to XPath which also operates on well-balanced XML fragments. It might be worth stating this explicitly.

Possible decisions:

1. Wrong: XPath oprates on well formed documents only
2. Keep as is
3. make the change requested

Resolution: The working group is tempted to follow XSLT and allow the document to have multiple roots, the core WG is defining Infoset defined for external parsed entities. Adding support for those.

[XP67] more flexible context initialization

Source: Michael Kay http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0039.html about the XPointer CR version

Summary: Application (for example XSLT) reuse of XPointer will be made difficult due to our strict definition of the context initialization

4) Section 5.2, bullets 4 and 5. This appears to ban applications from defining a way of binding variables and functions and using them in an XPointer, which seems unnecessarily heavy-handed, for example it would make it difficult to extend XSLT to use XPointer. Wouldn't it be better to say that the set of variable bindings is determined by the application, and is empty by default?

5) Section 5.2, bullet 6. This probably ought to say something about the default namespace, rather than leaving it implicit. Again, it seems heavy-handed to prevent namespaces being bound in some application-defined way, for example in an API that uses XPointer syntax this would make it very difficult to refer to namespace-qualified names.

Possible decisions:

1. keep as is, strict definition is needed for interoperability
2. relax section 5.2 to allow initialization by applications when XPointer is not used for strict URI Reference subresource resolution

Resolution: 1/ rejectcted on ground of interoperability. The problem of addressing namespace-qualified names is well know and should be addressed at the XPath level.

[XP68] Missing definitions for Points

Source: Michael Kay http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0039.html about the XPointer CR version

Summary: Points object definition lacks a couple of informations

6) The definition of the axes of a point location should include a definition of the parent and self axes. (It perhaps needs to be stated that the concept of an axis is *not* being generalized to return any location, it still always returns a node-set).

8) Section 5.3.2, second paragraph. The concept of two points being "equal" has not been defined. (It needs to be distinguished from the XPath "=" operator).

Possible decisions:

1. Define and add the missing informations for points (Suggestions ?)
2. Keep as is

Resolution: generated a long discussion, especially for point equality when one of the nodes may be at the origin or end of a text string. So there was no consensus to disallow case where points may be differents but undistinguishable at the rendering level. The editors are however instructed to make the distincion clear in the specification.

[XP69] problems with range-to()

Source: Michael Kay http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0039.html about the XPointer CR version

Summary: clarification on the impact of range-to() on XPath syntax is needed, and suggest a different syntax

9) Section 5.4.1, Note. This extension to XPath syntax needs much more formal treatment. Exactly how is the BNF modified? Which functions are allowed after a "/"? What are the semantics? I'm worried that this extension is "jumping the gun" in terms of how XPath evolves. I think that this kind of requirement, along with many others, would be much better met by allowing a function to take an expression (or function) as an argument, so it could be written say range-to(id("chap1"), function: following::REVEND(1]). (This concept is needed to do things such as universal and existential quantifiers, summing an arbitrary expression, etc).

Possible decisions:

1. keep as is
2. Details the productions affected in the XPath grammar and the exact changes allowed
3. Change the syntax to follow the suggestion

Resolution: after discussion between DV and Michael Kay a modification to production 4 of XPath is provided and the change is to be made to the specification

[XP70] Error detection and handling

Source: Michael Kay http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0039.html about the XPointer CR version

Summary: seems there is a bit of confusion in the description of error handling

12) Section 5.4.3 fourth paragraph. "the expression fails" - is this concept defined?

13) Section 5.4.3, function start-point(), fourth bullet. Suggesting this is a syntax error implies that it can be detected statically. This is not the case, for example start-point((*|@*)[5]): the argument may be an element or an attribute node. Same comment applies to end-point().

Possible decisions:

1. keep as is
2. link "the expression fails" to the proper definition
3. start-point() and end-point() should really reference sub-resource error

Resolution: agreed to change the errors to be sub-resource ones.

[XP71] Non-nodeset reults handling

Source: Michael Kay http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0046.html about the XPointer CR version

Summary: What happen if the XPath expression doesn't evaluate to a Node Set ?

16) I didn't see anything in the XPointer spec that says the XPath expression has to evaluate to a node-set. Since 2+2 is a valid XPath expression, it seems that XPointer(2+2) is a syntactically valid XPointer, though presumably it will always fail as "a scheme that does not locate any subresource present in the resource". However, the rule that the expression must return a node-set could be stated more explicitly; and in particular, the syntax of an XPointer could refer to an XPath UnionExpr rather than an XPath Expr, since an Expr that is not a UnionExpr will never return a node-set.

In fact the rules could be more restrictive than this. As a precedent, the XSLT syntax for Patterns describes a subset of XPath syntax that will always return a node-set. This subset is probably more restrictive than the subset that would be appropriate for XPointer, for example because it only allows use of the child and attribute axes, but the same idea could be applied.

Possible decisions:

1. keep as is
2. he's right define as a (sub resource) error if the expression evaluates to anything else than a (possibly empty) nodeset
3. Specify that an XPointer expression must be evaluated only as a LocationPath (production 1 on XPath) which can only return a nodeset

Resolution: 2/ agreed. add prose that anything returning anything other than a location set is a sub-resource error.

[XP72] Editorial suggestions

Source: Michael Kay http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0039.html about the XPointer CR version

Summary: mostly editorial only changes suggested:

• 1) Section 3.4: It would be better to use the same style of language as in section 3.3: "Specifications conform to XPointer if they permit URI references with fragment identifiers in relation to resources ... and if they use XPointer syntax and semantics for the fragment identifier.". Reason: W3C has no authority to "require" specifications to conform.
• 3) Section 5. The start of this section is rather confusing. It starts by saying that XPointer adds two new location types to XPath; but XPath does not have the concept of location types, it is a generalisation introduced by XPointer. It would almost be possible to fix this by reversing the order of the first two bullet points.
• 7) Section 5.3.2, first paragraph. This uses the concept of "document order", it would be helpful to include a forwards reference to section 5.3.5.
• 10) Section 5.4.2 second paragraph. This mentions XML normalization of line ends. It should also mention normalization of attribute values.
• 11) Section 5.4.3 third paragraph. "As defined in XPath" - where in XPath?
• 14) Section 5.4.6, function unique(), boxed example. I think this should read "last()=1". I also feel that this function is gratuitous: if it is worth having, it should be in XPath and not in XPointer.
• 15) Section 5.4.6, paragraphs from "Note that different" to the end. This text seems irrelevant to the section that it forms part of.

Possible decisions for each point raised:

1. keep as is
2. change as suggested, adding references where needed, etc...
3. for unique() keep the function but fix the example

Resolution: Editorial changes were agreed upon, and unique() was decided to be dropped from XPointer

[XP73] Resource or Infoset

Source: Paul Grosso (XML Core) http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0049.html about the XPointer CR version

Summary: XPointer working on resources or Infosets

How does the fact that "xpointer points into a resource whose mime type is XML" reconcile with the idea that xpointer points into an Infoset (or, specifically the "data model" defined by XPath, since XPath preceded the existence of an official infoset)?

Possible decisions:

Resolution: accept Eve wording as amended to keep the Infoset reference

[XP75] Editorial comments

Source: Susan Lesch http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0061.html about the XPointer CR version

Summary: three minor comments

In 3.4 par. 1, "(suitably escaping)" could read "(suitably escaped)". (Not certain.)

In 5.2 last example, should the namespace-uri be 'http://example.com/foo'?

In Appendix A, XML-Names, "Textuality, Hewlett-Packard, and Microsoft." can be omitted.

Possible decisions:

Resolution: Editorial, accepted, the editor are asked to close them

[XP76] suggest that some additional functions

Source: Lance Otis http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0065.html about the XPointer CR version

Summary: suggest that some additional functions

We would like to add some flexibility to the XPointer spec for document search.

Can the XPointer spec be changed to include functions such as similar-to(), find-by-concept(), and find-by-query() with the appropriate arguments?

Possible decisions:

1. this is a request for more feature during CR stage ...

Resolution: no new features, those are searching related and rather difficult to specify and implement

[XP77] a couple editorial errors

Source: Jeffrey Bacon http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0025.html about the XPointer CR version

Summary: a couple editorial errors

Section 5.4.2 string-range() Function, example 2:

Section 5.4.2 string-range() Function, example 3:

Section 5.4.6 unique Predicate Function

Possible decisions:

Resolution: Editorial, accepted, the editor are asked to close them

[XP78] Minor editorial correction.

Source: Elliotte Rusty Harold http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0071.html about the XPointer CR version

Summary: Minor editorial correction.

point into a non-final October 1999 draft of XPath,

Possible decisions:

Resolution: Editorial, accepted, the editor are asked to close them

[XP79] Minor correction.

Source: Elliotte Rusty Harold http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0071.html about the XPointer CR version

Summary: Minor correcction

 I'm not 100% sure of this, but I think that in section 5.4.3 Additional
Range-Related Functions the declarations of start-point and end-point
are incorrect. You have:

point start-point(point)
point end-point(point)

I suspect these should be 

point start-point(location-set)
point end-point(location-set)

That is, change the point argument to a location-set. 

Possible decisions:

Resolution: Right the editors were instructed to make the change

[XP80] Problematic Aspects of Ranges

Source: XSL/XML Linking Task Force http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0170.html

Summary: a subset of XPointer be created that eliminates ranges

We have observed that arbitrary ranges introduce some problematic 
situations for styling.  In any styling technology whose data model 
granularity is coarser than the Infoset (which includes both XSLT and CSS, 
for example), XPointer ranges might identify material that is not 
"compliantly" expressible in styling terms.  This problem is most acute in 
the case of embedding, and, more generally, in any case where the 
presentation context is equal to the ending resource.  There is also the 
tricky case of string ranges that begin or end in the middle of a presented 
multiple-character glyph.[9]

The XSL-affiliated members of the task force are working with that group on 
the data model issue and are recommending some extension functions to tide 
developers over.  We have also recommended some strategies for "sloppy" 
application of link behavior in cases where this is acceptable to all 
applications and users involved.[10]

However, for the sake of all styling technologies with the same problem 
(some of which may not be able to be upgraded in the near future), we 
recommend that a subset of XPointer be created that eliminates ranges (and 
possibly string ranges), in order to offer a version of XPointer whose data 
model has a better match with these technologies.  In this way, 
applications could choose to claim compliance to this subset or require use 
of it as appropriate.  This subset could perhaps take the form of a new 
scheme, such as #xptr-basic(...).

[9] http://www.w3.org/XML/Group/2000/08/NOTE-xml-link-style.html#range-ligs
[10] http://www.w3.org/XML/Group/2000/08/NOTE-xml-link-style.html#spec-range-display

Possible decisions:

1. Add a new 'xpath' scheme restricted to XPath expressions
2. Add another subset without ranges
3. keep as is

Resolution: 3/ The working group examined various options. The ensuing strawpoll clearly indicated that a large majority of the working group preferred to keep the range support as is and not provide an intermediate level of conformance.

[XP81] mismatch XPointer here() vs. DSig's here()

Source: XML DSig grouphttp://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Sep/0040.html

Summary: XPointer and XML DSig here() functions diverged again

[...]
Now the question occurs, if an Xpointer in an instance is interrupted 
by a processing instruction or a comment, what should "here()" return?
[...]

John Boyer was invited to the WG meeting to discuss it:

John Boyer: here() is expected to return the text-node/attribute/pi 
            containing it. The XPath transform in DSig 
            In order to do a signature they needed something similar
            to here() . Problem when here() append on textual content.
Eve: the spec doesn't handle the case of a non-single node.
John: for text node we return the parent element instead
Jonathan: here() cannot return an attribute node in practice.
          no problem to give back the parent instead.

Possible decisions:

1. result undefined
2. disallow multiple text nodes
3. return the parent element = DSig suggestion
4. allow and return all the text nodes
5. allow and return all the text ndes and interrupting nodes
6. get rid of here()
7. allow the construct and return the text node containing the h
8. allow the construct and return the text node containing the first char of the xPointer expression
9. return a single location that is a range

Resolution: 3/ The WG had to vote on the issue

[XP82] Editorial changes

Source: Daniel Veillard

Summary: formatting and examples

 - could it be possible to get numbering on the productions like
   any other spec ?
 - the fisrt example in 4.1.2 XML Escaping seems to have a problem,
   I read:
   xpointer(book/chapter position() <= 5)
   which is nonsense while I would expect
   xpointer(book/chapter[position() <= 5])
   from the context
 - the last example is wrong:
   xpointer(id('list37')/item[1]/range-to(following-sibling(item)[2])
   should be
   xpointer(id('list37')/item[1]/range-to(following-sibling::item[2])
   following-sibling is an axis, not a function :-)

See also related issue XP42

Possible decisions:

1. Yep change it
2. Keep as is

Resolution: 1/ fix those

[XP83] Conformance section

Source: Jose Kahan http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000OctDec/0027.html

Summary: Hard to find the conformance definition

On the other hand, the only way I could find out the conformance criteria
was by doing a word search on the document using the keywords given in
section 3. I have an idea of what is mandatory now, but I can't say I'm
100% sure if it's the whole spec or just some parts of it.

A more explicit conformance section, such as the one given in the SVG
spec[1] would have been made this clearer, for example by summarizing all
the functions and things (without going into detail) that are required,
optional, and so on.

[1] http://www.w3.org/TR/SVG/conform.html

See also related issue XP42

Possible decisions:

1. Rewrite part of 3.3 Application Conformance and make it more explicit
2. Keep as is

Resolution: 1/ Add a sentence saying there is no optional part and compliance can only be claimed by full implementation

[XP84] Scheme Registry and Mime-Types

Source: W3C staff review, CR exit criteria, Gavin Nicol, etc...

Summary: the scheme mechanisme possibly allows to reuse and mix new fragment identifier definitions, but the way the extension should be handled is unclea

The CR version simply disallowed defining new schemes, with a pointer to the errata page:

Because there is no way to avoid conflicts in scheme naming
and use, the only scheme allowed in this version of the
XPointer specification is xpointer. All other scheme names
are reserved. Users who want to define or use new schemes
are invited to check the XPointer errata document [ERR]
for a possible solution.

Though schemes served other schemes within XPointer it was suggested that this get fixed, and generated a voluminous discussion started in the level of conformance thread.

Possible decisions:

1. Drop scheme
2. find a new registrar
3. associate it with Mime-Types registration
4. allow to reuse the scheme parts of the XPointer definition

Resolution: 3/ and 4/ this was actually done by adding a scheme syntax conformance level in Section 3.3 and Section 4.3

[XP85] (was XL101) Parameters of URI usage in role attributes

Source: Eric van der Vlist http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0013.html

Summary: about URI references used by semantic attributes

About URI references 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 ?

Also see Jown Cowan's forwarded comment from Simon St. Laurent and ensuing thread.

Possible decisions:

1. Disallow relative URIs for arcrole and role
2. Absolutize and compare character-for-character
3. Status quo

Decision: 1/ Disallow relative URIs for arcrole and role

[XP86] MD1 Classes of XPointer

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0147.html

3.5 Classes of XPointer Errors
"syntax error":
"and applications must not attempt to evaluate it as an XPointer"
     This restriction conflicts with the last sentence of the section:
         "This specification does not constrain how
         applications deal with these errors."
     I'd remove the restriction.
     (If you think it should stay, then why isn't there a similar
     restriction for resource errors? Why is there no restriction on the
     location-set yielded by an XPointer with a sub-resource error?)

     In any event, discussion of how applications deal with syntax errors
     should not be within the *definition* of "syntax error".

Possible decisions:

1. Remove the restriction.
2. Move the restriction to the conformance section somewhere.
3. Keep as is.

Decision: the xpointer expression is evaluated left to right, if a sub-resource error is found when evaluating a scheme then the processing should be done on next scheme, but if it is a syntax error the evaluation stops.

[XP87] MD2: XML Escaping

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0147.html

4.1.2 XML Escaping
"Note that if XML-based languages define elements or attributes containing
URI references (such as XLink's href attribute shown above), the relevant
element content or attribute values also require the processing defined in
4.1.1 URI Reference Encoding and Escaping."
     So shouldn't you complete the example by performing this processing?
     You could put the final result in a third box, so that the result of
     just the XML-escaping is still clear from the first two boxes.

     You might also note that if the URI-escaping were performed first, it
     would (among other things) change "<" into "%3C", which would (1) make
     XML-escaping unnecessary, and (2) result in a slightly different
     fragment identifier for the same XPointer.

Eve said about this one:

I'm inclined not to follow his suggestions, just to keep the section 
simple.  Any opinions?  And a sanity check: Is he right about URI-escaping 
obviating the need for XML-escaping?

Possible decisions:

1. Provide a third example showing XML-escaping and URI-encoding.
2. Note that URI-escaping, done first, obviates the need for XML-escaping (if true!).
3. Both #1 and #2.
4. Keep as is.

Decision: This generated a large thread involving Martin Duerst. Jonathan made a proposal it was discussed with Martin which suggested some clarifications. This is a 3 steps processing. editor to add the description of this processing in a new 4.1.1 section.

[XP88] MD3: Forms of XPointer

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0147.html

4.2 Forms of XPointer
StringWithBalancedParens:
     The EBNF does not admit escaped (unbalanced) parentheses. Yes, the
     validity constraint allows them, but I think it's unusual for a VC to
     be more permissive than the EBNF. Normally VCs are more restrictive.
     In the EBNF, you could change "[^()]*" to
         ( [^()] | '^' [()] )*
     which you might want to split off into its own production.

     (This, like the original, allows arbitrary occurrences of circumflex.
     You could disallow it in the EBNF, but only by having two different
     uses of circumflex in the same expression. In the VC, you might want to
     say "Any other occurrence of circumflex results in a syntax error.")

Eve said about this:

In this case, I'm inclined to leave the BNF nice and simple, and instead 
change the last sentence in the VC from:

"If the unescaped parentheses in the expression are not balanced, a syntax 
error results."

to:

"Any other occurrence of a circumflex results in a syntax error."

Possible decisions:

1. Build the circumflex into the BNF, adding a new production to clarify things, and add his suggested note in the VC.
2. Leave the BNF alone and change the wording in the VC as I suggest.
3. Keep as is.

Decision: Keep the BNF as it is, add a sentence about the extra syntax rules not expressed by the BNF. Gavin Nicol objected.

[XP89] MD4: Definition of Point Location

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0147.html

5.3.1 Definition of Point Location
"the location preceding any individual character ... in an XML document":
     Might as well say "preceding or following", as with nodes.

     Actually, a point can't represent *any* such location, in particular
     it can't represent locations between markup characters.

David simply said about this:

He is correct.

Chris said about this:

We should be more careful; what we really mean is any individual character 
that would create a character information item if we were using the 
infoset: i.e., characters in text nodes, attributes, processing 
instructions, comments.  Markup, as such, doesn't exist in our data model 
and is therefore not addressable.

Possible decisions:

1. Add a note or paragraph explaining that markup characters don't count.
2. Keep as is.

Decision: just add "of the data set constructed from" before "of an XML document".

[XP90] MD5: Definition of Point Location II

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0147.html

5.3.1 Definition of Point Location
     What about the `parent' axis? Does a point location have a parent?

     What about the `preceding' and `following' axes?

     What about the `self' axis? One guesses that it would contain just
     the point itself.

Possible decisions:

1. Spell out the values for point-location axes (what are they?).
2. Keep as is.

Decision: following and preceeding are also empty axes for points.

[XP91] MD6: Definition of Range Location

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0147.html

5.3.2 Definition of Range Location
     Can the start and end points be in different entities?

Chris said about this:

Yes.  Our data model is entity ignorant, except for base URIs, 
right?  Consider:

<!DOCTYPE xmp [ <!ENTITY foo "bar"> ]>
<xmp>This &foo; is closed.  Go home.</xmp>

If you make a range from the start of the singular text node to a point seven characters in, you've crossed an entity boundary. David said about this:

Yes, since a point is a pair of a node and a child-number, and a range is 
just a pair of points.

Possible decisions:

1. Add a note about this in this section.
2. Keep as is.

Decision: inherited and defined in XPath

[XP92] MD7: Definition of Range Location II

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0147.html

5.3.2 Definition of Range Location
"The axes of a range location are the axes of its start point."
     So if the `self' axis of a point contains just the point,
     then the `self' axis of a range contains just its start point,
     which is probably not what people would expect.

     Some of the other axes (e.g., `parent' and `following') are also a bit
     odd under this definition. Not that that's wrong, but it might be
     worth a note saying, "yes this is intentional".

David said about this:

This answers the question of what these axes mean. I don't have idea if 
these definitions are confusing, because I don't have a strong 
presupposition about what they _should_ mean.

Possible decisions:

1. Spell out the values of all the axes for ranges.
2. Do #1, plus add a note or paragraph that explains the oddness.
3. Keep as is.

Decision: the definition as given is kept, but the editors will add an example to clarify

[XP93] MD8: Covering Ranges for All Location Types

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0147.html

5.3.3 Covering Ranges for All Location Types
"This definition ensures that for a range location, [various axes] do not
intersect and that they together contain all locations in the document
(other than attribute, namespace, and range locations)."
     I think this paragraph is misplaced. I don't see how the definition of
     "covering range" has anything to do with establishing how a range's
     axes partition the document. In fact, the only use I see of the term
     "covering range" is in the definition of the "range" function. Maybe
     the content of this section should be moved there.

Eve said about this:

He may be right, but I'd like to keep the restructuring to a 
minimum.  Would it work to move the final paragraph to the main section 
that defines ranges, and reword so that it doesn't seem to provide a 
rationale for anything?

Possible decisions:

1. Move the content of 5.3.3 to the range() function discussion.
2. Move only the final paragraph and reword as suggested above.
3. Keep as is.

Decision: keep the definition but remove the final paragraph of the final bullet point

[XP94] MD9: Covering Ranges for All Location Types II

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0147.html

5.3.3 Covering Ranges for All Location Types
     And I think you'll have to add point locations to the "other than"
     list. As far as I can tell, no axis contains a point location except
     for the self axis of a point (or range, see above).

Chris said about this:

Erm.  I *think* he's right.

David said about this:

I believe that he's right about where points can show up. Whether that 
decides the list-membership question isn't clear to me. In fact, the whole 
comment at the end of the definition seems opaque to me. The only place 
the words "covering range" appear outside 5.3.3, is in 5.4.3, in the 
definition of the "range() function"

Possible decisions:

1. Do as Michael suggests.
2. Keep as is.

Decision: MD8 decision makes it moot, this paragraph is removed

[XP95] MD10: range-to Function

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0147.html

5.4.1 range-to Function
prototype:
     Change "expression" to "location". (Every argument is an expression.
     The prototype must give the expected type of the value of the
     argument.)

Possible decisions:

1. Make the suggested change.
2. Keep as is.

Decision: make the change

[XP96] MD11: string-range() Function

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0147.html

5.4.2 string-range() Function
prototype:
     Delete space between "location-set" and comma.

Possible decisions:

1. fix this

Decision: okay purely editorial

[XP97] MD12: string-range() Function II

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0147.html

5.4.2 string-range() Function
the resulting range:
     What happens if third and/or fourth arguments specify positions that
     lie outside the string-value of the location?

David said about this:

It should be a sub-resource error, if it isn't.

Possible decisions:

1. Make this a sub-resource error.
2. Make it some other kind of error.
3. Keep as is.

Decision: accepted mostly solved in a slightly different way by defining it an XPointer scheme part error. Accepted by existing clarification and substituting "string" by "position"

[XP98] MD13: string-range() Function III

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0147.html

5.4.2 string-range() Function
"indicates a string that is beyond":
     You mean wholly beyond, or even just partly beyond?

Eve said about this:

To me, this prose means "wholly", but I think our intent is "partly or 
wholly."  Can I get an amen?

Possible decisions:

1. Clarify that we meant "partly or wholly."
2. Clarify that we meant "wholly."
3. Keep as is.

Decision: Accepted by existing clarification and substitute "the third or fourth argument indicates a string" by "the third or fourth argument indicates a position"

[XP99] MD14: Additional Range-Related Functions

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0147.html

5.4.3 Additional Range-Related Functions
range-inside:
     The definition seems to ignore the possibility that x might be a point
     location: a point can't be a container.

Chris said about this:

It could be just a sub-resource error, but that's kind of a cop-out.

Possible decisions:

1. Define range-inside for a point as being the point itself.
2. Define it as being a sub-resource error.
3. Keep as is.

Decision: 1/ Define range-inside for a point as being the point itself.

[XP100] MD15: Additional Range-Related Functions II

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0147.html

5.4.3 Additional Range-Related Functions
"the function must signal a syntax error":
     Change to "no point is added to the resulting location-set".

David said about this:

I'd prefer it to be a sub-resource error (as it seems semantic). If it's 
possible to determine that this error has occurred _without_ accessing the 
document, then it _could_ be a syntax error under the rules that we've adopted.

Possible decisions:

1. Change as Michael suggests.
2. Change to be a sub-resource error.
3. Change to be a syntax error.
4. Keep as is.

Decision: start-point() got fixed but not end-point() fix it in the same way: the XPointer part in which the function appears fails

[XP101] MD16: here Function

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0147.html

5.4.4 here Function
"syntax error":
     I think "resource error" would make more sense.

Eve said about this:

I tend to agree with him, since the problem is a resource mismatch and can 
be determined by the act of accessing the resource.

David said about this:

This is a harder one, since we can't define the semantics of here() except 
in an XML document, and furthermore, any author (or program) creating 
XPointers in a non-XML document could be reasonably be expected to avoid 
this problem. These are reasons to keep things as they are.

However, this means that there are essentially two XPointer _syntaxes_ 
depending on whether one is parsing within an XML document. This seems an 
undue burden on Xpointer parser implementors. I'd be inclined to make this 
a sub-resource error on that account.

Possible decisions:

1. Change to be a resource error.
2. Change to be a sub-resource error.
3. Keep as is.

Decision: make the XPointer part in which the here() function appears fail

[XP102] Editorial: Susan Lesch comments

Source: Susan Leschhttp://lists.w3.org/Archives/Public/www-xml-linking-comments/2001JanMar/0026.html

The RFC 2119 key words are listed under 3, but are used throughout.
Would it make more sense to place that definition under 1.2?

Recommendation: There are three likely places to put this information: 1.2 (Notation and Document Conventions), 2 (XPointer Terms and Concepts), and 3 (XPointer Processing and Conformance). Picking the first seems better than the last. Let's accept the comment.

In 4.2.1 and 5.4.2, whitespace -> white space (if you want to
follow XML 1.0, see http://www.w3.org/TR/REC-xml#sec-white-space).

Recommendation: Accept the comment.

In A.2 References, I imagine that you will update the editors and
date of XIS.

Recommendation: Accept the comment.

Deleting rowspan="1" colspan="1", and the thead and tbody elements
from the tables in 4.1.3 will save a few bytes in file size. Is
there some kind of production script that inserts these? It's
hardly a problem in XPointer, but adds up in other XML specs with
more tables.

Recommendation: The production of the HTML output is controlled by an XSLT stylesheet, but this is a low-priority change. Accept the comment if we can find the resources to change the stylesheet.

Decision: changes were accepted

[XP103] Editorial: Status of document with respect to Sun patent

Source: Andrew Watt http://lists.w3.org/Archives/Public/www-xml-linking-comments/2001JanMar/0038.html

The suggested changes apply to the "Status of the Document" section which 
currently reads, "XPointer is affected by a technology patent held by Sun 
Microsystems. The legal terms and conditions offered by Sun to XPointer 
implementors can be found in the archives of the public comments list.".

To the best of my knowledge there is no reason whatsover to believe that ALL 
of XPointer is affected by Sun's claimed patent. I suggest that there be 
redrafting to indicate those aspects of the XPointer specification to which 
the Sun patent **may** apply.

Thus the paragraph would more appropriately start, "Certain parts of XPointer 
may be affected by a technology patent held by Sun Microsystems. [specify 
here if you wish]."
...

Possible decisions:

1. Change the wording to "Certain parts of XPointer may be affected by a technology patent held by Sun Microsystems."
2. Change the wording in some other fashion.
3. Keep as is.

Recommendation: #1.

Decision: the working group recommends to change it to something like "Certain parts of XPointer may be affected by a technology patent held by Sun Microsystems.", but ultimately the sentence is in the Status so it's under the W3C staff responsability to make this change.

[XP104] Location set vs. XPath node list

Source: Andrew Watt http://lists.w3.org/Archives/Public/www-xml-linking-comments/2001JanMar/0039.html

It seems to me that there is an error in the 8th January 2001 XPointer WD.

It states as a definition of "location-set":
"An ordered list of locations, such as produced by an XPointer expression. 
This corresponds to the node-set that is produced by XPath expressions, 
except for the generalization to include points and ranges."

However the November 1999 XPath Recommendation defines a node-set as:
"an unordered collection of nodes without duplicates"

Thus there appears, contrary to the XPointer WD, to be a further distinction 
between an XPointer location-set and an XPath node-set in that the 
location-set is _ordered_ while an XPath node-set is _UNordered_.

The alternative interpretation is that if an XPointer location-set is a 
generalisation of an XPath node-set to include points and ranges then it too 
is unordered. I couldn't readily find clarification in the XPointer WD.

Possible decisions:

1. Replace "location-set" everywhere with "location-list" (several dozen occurrences), and add to Section 5 a description of this particular extension to XPath.
2. Change the definition of "location-set" to be "an unordered set of locations" and change any functionality (is there any?) that depends on the order of locations.
3. Keep as is.

Decision: Accepted, the definition of location-set is changed to:

"An unordered list of locations, such as produced by an XPointer expression. This corresponds to the node-set that is produced by XPath expressions, except for the generalization to include points and ranges. Just as for a node-set, a location-set is treated as having a specific order depending on the axis that is operating on it. However, this ordering depends on XPointer's extended notion of document order as defined in Section 5.3.5, rather than XPath's original notion of document order."

[XP105] Allow additional schemes for */xml media types

Source: C. Michael Sperberg-McQueen http://lists.w3.org/Archives/Public/www-xml-linking-comments/2001JanMar/att-0053/01-xptrrev.html

The end of para 1 suggests that the extension facilities described
here are to be used only with MIME types other than text/xml,
application/xml, etc.  If it were feasible (I bow to the considered
opinion of the WG on this), I think it might be useful to allow
extensions even in material shipped with these types.  The example I
have in mind is XML Schema.  XML Schema documents are likely to be
shipped as text/xml or application/xml (the XML Schema spec is to be
agnostic on this point), but users would, I think, benefit from a
scheme allowing the simple identification of arbitrary schema
constructs by reference to their nature and local name, without
reference to the element structure of the schema document in which
they happen to be declared.   I don't see any severe problems arising
in consequence, but this may reflect naïveté on my part
and I am willing to be enlightened.

Section 3.3 seems to imply the opposite, that unknown schemes
will be skipped (not treated as errors) in fully conformant applications.
That suggests that the wording here might need to be revised.

Possible decisions:

1. Allow additional schemes for */xml.
2. Keep as is.

Recommendation: #1. Were we to allow arbitrary additional schemes for */xml, the registration document for these media types would need continual maintenance. Our "scheme scheme" was intended to allow for extensibility through exploitation of the media type registration process, so that neither W3C nor IETF would be in a position to have to keep track in a central way.

On the matter of the implication that additional schemes are okay, the point is to allow resources to be served up under several media types without breakage of URI references that point into them, so this is consistent.

Resolution: not accepted, Eve gave an answer to Michael on this issue, and both the WG and Michael accepted it

[XP106] Editorial: Sperberg-McQueen comments

Source: C. Michael Sperberg-McQueen http://lists.w3.org/Archives/Public/www-xml-linking-comments/2001JanMar/att-0053/01-xptrrev.html

Section 3.3 Application conformance: For "items comprising minimal 
conformance" read "items comprised in minimal conformance" or "items included 
in minimal conformance".

Recommendation: Accept the comment.

Section 4.1.1 Escaping Contexts: For the reference to IURIs you should 
probably now substitute a reference to IRIs, as defined by Masinter and 
Dürst's Internet draft.

Recommendation: Accept the comment.

Decision: Accepted

[XP107] Resolve Sun patent situation before CR

Source: Wayne Carr http://lists.w3.org/Archives/Public/www-xml-linking-comments/2001JanMar/0063.html

We are very concerned about the IPR situation in XPointer.   We don't think
precedent should be set for the type of terms that are being required for
IPR on XPointer.  The group should attempt to work around the patent before
proceeding to Candidate Recommendation.

Possible decisions:

1. Proceed to PR (our next planned step) without any change in the patent situation.
2. Proceed to PR expecting that a resolution in the patent situation will occur before W3C will accept XPointer as a Recommendation.

Decision: Reject, unfortunately it's not workable at the XML Linking Working Group level. This need to be handled at the Company and W3C level, this may influence the way W3C members will vote at the Proposed Recommendation stage or even whether Proposed Recommendation is granted.

The working group has not resolved the issue and defer the treatment of this issue to the next layer of processing.

[XP108] Assign namespace name to XPointer

Source: Henry Thompson http://lists.w3.org/Archives/Public/www-xml-linking-comments/2001JanMar/0074.html

I agree that it's not immediately obvious that there's any need for a
namespace URI in the short term, but it wouldn't hurt to establish it
now for future use, e.g. to have an XML Schema with a simple type
definition for the XPointer subset of xs:uriReference.

Possible decisions:

1. Assign a namespace name for XPointer.
2. Keep as is.

Resolution: We will use http://www.w3.org/2001/05/XPointer

[XP109] (Mostly) editorial: Mark Polman comments/questions

Source: Mark Polman http://lists.w3.org/Archives/Public/www-xml-linking-comments/2001JanMar/0073.html

1) In Section 5.3.4, two new tests for location selection are 
introduced: "point" and "range".
 
Does anybody have an example of a situation in which these
tests actually return a non-empty location set?
 
The only one I can think of is self::point(), under the condition
that the context location is a point.
 
It seems to me that an axis can only preselect node-locations and
point-locations (only in the case of a "self"-axis). How would it be
possible to select ranges from these?

Is there an issue with this part of the spec?

5.3.4 Tests for point and range Locations

        XPointer extends the XPath production for NodeType by adding
        items for the point and range location types. That production
        becomes as follows:

        NodeType

         [11]   
              NodeType
                          ::=   
                            'comment'
                            | 'text'
                            | 'processing-instruction'
                            | 'node'
                            | 'point'
                            | 'range'


        This modified definition is included here in order to insure
        that there is a node test for every kind of location.  In
        principle it allows NodeTests to select locations of type
        point or range from a location-set that might include
        locations of more than one location type.

        NOTE: In practice such sets are unlikely to arise other than
        artificially, but as implementation simply requires filtering the
        current location set by location type, the implementation burden
        is slight.

2) In Section 5.3.1, the axes of a point location are defined. What
is the point of the last item: "A node-point's siblings...after the
node-point", when before it is stated that the preceding-sibling and
following-sibling axes are empty?

Is there an issue with this part of the spec?

Decision: redefine precisely the various axis for points, add a graphic to make the relationship between sibling points clear.

3) Also, what is the definition of the "following" and "preceding" axes?
Are they delegated to the XPath semantics?

Recommendation: Respond "yes".

Decision: the "following" and "preceding" axes are added (in the first bullet of the list) as empty.

4) Also, is there a reason why items 3 and 4 explicitly refer to
NODE-points instead of just points?

Possible decisions:

1. Replace "node-point" with "point" globally.
2. Keep as is.

Decision: Accepted, replace "node-point" with "point" in 3, 4 and 5

[XP110] Editorial: Michael Dyck general/header comments

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2001JanMar/0054.html

In general, I think the spec would be ultimately clearer (especially to
those who would introduce a new scheme) if it were structured as two specs,
one that defined the general XPointer framework, and another that defined
two schemes ('xpointer' and 'xmlns') that fit into that framework.

At the very least, it would be less confusing if the spec used different
terms for the two things. (E.g., "XFragmentIdentifier" [XFragId] for the
general framework, and "XLocator" or [the existing] "XPtrExpr" for the
`xpointer'-specific expressions.)

Possible decisions:

1. Split XPointer into two specs.
2. Invent and use a different name for xpointer()-scheme XPointers to distinguish them from XPointers of arbitrary type.
3. Keep as is.

Recommendation: #2.

Decision: The working group did not reach consensus on splitting the specification, largely because the perceived cost of such a major structural change late in the process would outweight the benefits.

Decision: keep the terminology as is, Eve made an analysis and it seems we use XPointer uniformly in the spec to mean the full interpretation of XPointer.

Throughout, change
    "[IETF I-D XMT]"
to
    "[IETF RFC 3023]"
and delete the "Internet Draft" that occasionally precedes it.

Recommendation: Fix here and in Appendix A.

Status of This Document: 4th para:
"This document is intended to be taken in conjunction with [x], in order for
that document to officially designate XPointer ..."
    Awkward construction. How about just:
    "It is intended that [x] officially designate XPointer ..."

Recommendation: Keep as is. This spec has been developed with the knowledge of the authors of the eventual registration document, which is what we mean; plus, the suggested wording isn't much less awkward than the present wording.

Status of This Document: 4th para:
Italicize "XML Media Types"?

Recommendation: Keep as is.

Status of This Document: 4th para:
"However, because of the timing problem associated with publishing two
related documents on separate tracks, currently that document ..."
    It's not so much the timing problems of publishing, but simply the fact
    that the XML Media Types document came into existence before the
    XPointer document reached Recommendation stage.
    Change to "Currently, that document ..."
    Maybe join it to the next sentence with "but".

Recommendation: Accept both parts of the comment.

Decision: purely editorial let the editor decide

[XP111] Editorial: Michael Dyck Section 1 comments

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2001JanMar/0054.html

Introduction: 1st para:
"IETF RFC 2376"
    Obsoleted by "IETF RFC 3023".

Recommendation: Fix here and in Appendix A.

Decision: accepted

Introduction: 1st para:
Section 5.2 (first bullet) makes it clear that "an application [may use]
XPointers in another context than as a URI reference's fragment identifier",
but it would be helpful if you said this in the introduction too.

Recommendation: Accept the comment.

Introduction: 1st para:
-- 4th para, 3rd bullet:
"in URI references as fragment identifiers"
    -> "as fragment identifiers in URI references"

Recommendation: Reword the entire third bullet as "Be used in URI references to address into resources" and move it to be the first bullet.

Decision: Reword the entire third bullet as "Be used in URI references to address into resources" and move it to be the first bullet.

Introduction: 1st para:
Note:
"the basis of"
    Vague? Change to "the language for"?
"XPointer is intended ... only for [text/xml, etc]"
    No, not *only* those resources, as the rest of the note goes on to say.
    Maybe "primarily" or "initially", but not "only".

Recommendation: Change "XPointer is intended to be the basis of" to "XPointer is defined to be the language for". Change "XPointer is expected to be useful as a fragment identifier language for the generic XML aspects of those media types" to "However, XPointer is also suitable to be used as the basis for new fragment identifier languages for other XML-based media types." This note was not properly updated when we invented the new "scheme scheme."

1 Introduction: 1st para:
"a recent Internet Draft [...] suggests the use of a naming convention ..."
    -> "[IETF RFC 3023] encourages the use of the suffix "+xml" ..."

Recommendation: Accept the comment.

1.2 Notation and Document Conventions: last para:
"[XPath] is the normative version"
    "version" -> "reference" ? "specification" ?

Recommendation: Change to "XPath is normative."

[XP112] Editorial: Michael Dyck Section 2 comments

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2001JanMar/0054.html

Definition: range
    "end points" -> "points"
    (The rest of the spec is consistent in using "end point" only in contra-
    distinction to "start point", and not as a catch-all for both.)
Definition: location
    "range" -> "ranges"

Recommendation: Accept the comments.

Definition: singleton
    "A point is always a singleton. A range is always a singleton as well,"
    No, this is a confusion of categories. A point or range is a *location*,
    not a *location-set*. Thus, it is meaningless to speak of a point or
    range being a singleton or not.

    Maybe this definition should be deleted, given that the only use of the
    term outside this definition is, in fact, a mis-use. (See 5.3.2.)

Recommendation: Delete the definition and the text in Section 5.3.2 that says "(encompassing both these nodes, but still a singleton)". Our further refinement of the definitions of location and location-set over time has made the concept clear enough.

Definition: sub-resource
    "is an XML document" -> "may be an XML document"
    (Since it might instead be an external parsed entity.)

Recommendation: Change to "is an XML document or external parsed entity ... inside the document or entity".

Decision: suggestions in this section were editorial and the editor is allowed to do the required word-smithing.

[XP113] Editorial: Michael Dyck Section 3 comments

Source: Michael Dyck http://lists.w3.org/Archives/Public/www-xml-linking-comments/2001JanMar/0054.html

3.3 Application Conformance:
I think it would be useful for the definition of application conformance and
classes of errors, to define an "XPointer-processor" abstraction. The
definition would go something like this:
    Given a resource (purportedly an XML document or external parsed entity)
    and a string (purportedly an XPointer), an XPointer-processor yields the
    subresource (location-set) identified by the XPointer or else an error.

Then, for instance, instead of phrasing such as
    "Minimal conformance entails ..."
(which avoids even a referent for the thing whose conformance is in
question), one could say
    "An XPointer-processor is minimally conforming if it ..."

Recommendation: Add the recommended definition as the first sentence of the first paragraph in Section 3.3 (except remove the hyphen in the new term). Change the (now) second sentence in that paragraph to "two levels of conformance of XPointer processors". No other changes are needed to the spec, which routinely refers to "XPointer processing" -- which will be understood as a clear reference to the newly defined term. (He has other comments that invoke this new concept, and I find it helps in these cases, so new mentions of "XPointer processor" might be added if those comments are accepted too.

Decision: add the definition of an XPointer-processor but add the fact that it is fully conformant.

-- Definition: Minimal conformance:
"series of XPointer parts" -> "FullXPtrs"

Recommendation: Keep as is. "XPointer part" is well defined as a prose synonym for the FullXPtr nonterminal, and its instance here is linked to the definition.

"routing XPointer parts with particular schemes to an application that
can evaluate those parts"
    This wording seems fairly implementation-specific. From the point of
    view of someone judging the conformance of XPointer-handling software,
    whether that software routes parts to other applications is immaterial.

Recommendation: Not sure. Would saying "handling each scheme appropriately" be more abstract and yet helpful enough?

Decision: kee as is, we don't see it as a point of confusion since it describes an abstract model.

The placement of the closing bracket is arbitrary. Move to end of sentence.

Recommendation: Accept the comment.

So, as long as it handles bare names, an XPointer-processor that yields a
sub-resource error for every FullXPtr is minimally conforming, since it can
claim not to understand any schemes.  In which case, why not just say that
minimal conformance only entails interpretation of bare names?

Recommendation: Keep as is. Minmal conformance also entails proper handling of the "scheme scheme," however we choose to word our description of this handling.

Decision: keep as is, this is a divergence in interpretation of what is an XPointer processor, it must understand the xptr scheme

last para:
"for the convenience of XML-based Internet media types"
    Maybe insert "other" before "XML-based".

Recommendation: Keep as is. The rest of the sentence makes clear that we mean media types other than the ones for which XPointer itself will be mandated.

3.4 Classes of XPointer Errors:
Definition: resource error:
"If a syntactically correct XPointer ... is appended to a URI that
identifies no resource, ... the XPointer has a resource error."
    This is odd. If a URI identifies no resource, then there is no media
    type, and thus no fragment identifier language (FIL). So it's a moot
    point whether the fragment identifier is an XPointer, and "even mooter"
    whether the fragment identifier is erroneous. The XPointer-processor
    would presumably not even be invoked in such a case.

As for "a URI that identifies ... a resource that is not well-formed XML",
    this includes resources of most media types (e.g., image/jpeg,
    audio/mid, text/plain), and these do not use XPointer as their FIL.
    Thus, again, it is incorrect to think of the fragment identifier as an
    XPointer.

    In fact, even if the resource *is* well-formed XML, it doesn't
    necessarily have a media type that uses XPointer as its FIL. So it
    *still* might be incorrect to think of the fragment identifier as an
    XPointer.

Moreover, the definition suggests that whether an XPointer has a resource
    error is determined when it is appended to a URI, but this is presumably
    not what was intended.  Whether a URI identifies a resource, the content
    of that resource, and the media type of that resource, all vary over
    time. Thus, whether an XPointer has a resource error would depend on
    when the URI is resolved.

I think all of these problems would be solved by rephrasing the errors in
    terms of an XPointer-processor abstraction:

    If the string passed to the processor does not match the syntax 
    specified in this document, the processor yields a syntax error.

    Otherwise, if the resource passed to the processor is not a well-formed
    XML document entity or external parsed entity, the processor yields a
    resource error.

    Otherwise, the processor attempts to evaluate the XPointer with respect
    to the resource as described in section 4. If the evaluation fails as
    discussed in 4.3 Schemes, the processor yields a sub-resource error.

Note that this doesn't mention URIs at all, which is as it should be, since
    "resource error" is a meaningful concept whether the XPointer is the
    fragment identifier of a URI or not.

Recommendation: Though this may seem like a fairly invasive change, I recommend making it. It is much better motivated than the current wording, while not changing the intent at all and while leveraging the entirely natural definition of "XPointer processor" that I recommended accepting above.

Decision: left to the editor, seems there is a bug in the second paragraph, (addition) "Otherwise, if no resource or an empty resource is passed to the processor, the processor yields a resource error."

Decision: other items in this groups were considered editorial and letf to the appreciation of the editor

[XP118] Michael Dyck Section 5 comments

[XP119] Michael Dyck Section 5.2 comments

[XP120] Michael Dyck Section 5.2.1 comments

[XP121] Michael Dyck Section 5.3 comments

[XP122] Michael Dyck Section 5.3.1 comments

[XP123] Michael Dyck Section 5.3.2 comments

[XP124] Michael Dyck Section 5.3.3 and 5.3.4 comments

[XP125] Michael Dyck Section 5.3.5 comments

[XP126] Michael Dyck Section 5.4 and 5.4.1 comments

[XP127] Michael Dyck Section 5.4.2 string-range() comments

[XP128] Michael Dyck Section 5.4.3.2 range-inside comments

[XP129] Michael Dyck Section 5.4.3.3 start-point() and 5.4.3.4 end-point() comments

[XP130] Michael Dyck Section 5.4.4 here() and 5.4.5 origin() comments

[XP131] Michael Dyck Section remaining comments

[XB1] Do intra-document hrefs participate in xml:base?

Source: IG - http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Jan/0058.html

Summary: Does anything in XBase need to be changed to reflect that relative URI references consisting only of a fragment identifier do NOT consider the base URI when they are resolved

Possible decisions:

1. Yes, this is desireable and the xml:base spec should note it.
2. Yes, but this is broken and the whole concept of xml:base needs to be revisited.
3. No, the xml:base spec should clarify this.
4. No, everything is fine as is.

Resolution:

4/ No, everything is fine as is.

[XB2] XBase" abbreviation is confusing

Source: Steve Hodgkiss, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0051.html

Summary: The term "XBase" previously referred to dBase, FoxPro, Clipper, et. al. as in the "XBase World" or "XBase Community". Unique terminology would be welcomed.

Possible decisions:

1. Keep Xbase
2. Change XBase occurences to "XML Base"
3. Change XBase occurences to something else

Resolution: 2/ agreed ! All occurences of "XBase" will be replaced with "XML Base"

[XB3] XBase: unsetting the base URI

Source: Richard Tobin, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0051.html

Summary: Can the base URI infoset property be explicitly set to unknown by specifying xml:base=""?

It seems that this or some such syntax is needed to allow serialisation of an infoset that contains elements with unknown URI nested inside elements with a known URI. (Presumably such an infoset would have to be created by hand.)

Possible decisions:

1. Agreed, add a note on the topic
2. Wrong, here is the explanation.

Resolution: 2/ this is not a good idea, considered withdrawn

[XB4] I18N: scoped attribute support

Source: Martin Duerst, http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Mar/0020.html

Summary: The XML Base spec defines an attribute xml:base that works in a nested/inherited way. This is similar to xml:lang. Support for such attributes in W3C technologies, e.g. in XSLT or XML Schemas, is currently scarse if not inexistent. The I18N WG/IG hopes that both groups can use their contacts to make the relevant W3C WGs aware of the need for such support.

Possible decisions:

1. Wrong
2. Agreed, no change required
3. Agreed, add a note on the topic (with XPath example)

Resolution with clarification by P.Grosso: Closed without action, check XB7 resolution

[XB5] I18N: reference character model

Source: Martin Duerst, http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Mar/0020.html

Summary: For URIs, RFC 2396 (URIs) is referenced directly, without taking the provisions of http://www.w3.org/TR/charmod/#URIsinto account. This should be corrected.

Possible decisions:

1. No
2. yes, but this is currently only at WD status c.f. anwer to request

Resolution: basically 2/ grab XPointer and XLink snippet about the character model and incorporate it into XML Base

[XB6] I18N: scoping into external entities

Source: Martin Duerst, http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Mar/0020.html

Summary: There is some text in Section 3 saying 'Note that the scope of xml:base does not extend into external entities. This is in keeping with xml:space.' The I18N WG/IG is worried that this may create an unnecessary difference to how xml:lang is handled. However, we are not sure we fully understand the issue. We therefore ask you to provide an example that shows the difference between not extending into external entities and extending into external entities, so that we can check this issue further.

Possible decisions:

1. No keep as is
2. yes, clarify the section
3. yes, add an example

Resolution: The scoping wording is unclear, it need to be clarified. The Working Group examined the problem of scoping withing external entities and decided to keep the current status-quo, i.e. not have base to scope within external entities.

[XB7] XML Base like xml:space/xml:lang

Source: XML Core WG discussions,

Summary:

The last paragraph of section 3
http://www.w3.org/TR/2000/WD-xmlbase-20000221#AEN1_4_2_3 reads:

Note that the scope of xml:base does not extend into external entities. This is in keeping with xml:space.

and the last sentence of the second paragraph of section 2 http://www.w3.org/TR/2000/WD-xmlbase-20000221#AEN1_4_2_2 reads:

This enables scoping behavior consistent with the xml:lang and xml:space attributes.

References to the behavior of xml:lang and xml:space are potentially confusing and at best unnecessary and cause potential cross-dependencies that needn't be there and should be deleted.

Possible decisions:

1. Delete the last sentence of each referenced paragraph
2. Reword things to mention xml:lang and xml:space in such a way that there is no normative dependency
3. Leave worded as is

Resolution with clarification by P.Grosso: 1/ remove both sentences

[XB8] XML Base scope

Source: XML Core WG discussions

Summary:

Whereas the last paragraph of section 3 http://www.w3.org/TR/2000/WD-xmlbase-20000221#AEN1_4_2_3 says that the scope of xml:base does not extend into external entities, and the second paragraph of section 2 http://www.w3.org/TR/2000/WD-xmlbase-20000221#AEN1_4_2_2 starts:
The base URI specified by xml:base sets the base URI information set property of the element on which this attribute occurs, and to its descendants except where further xml:base attributes are applied.
there is no clear positive statement about the scoping of xml:base. We should add such to the spec.

Possible decisions:

1. Direct the editor to augment the wording of the second paragraph of section 2 accordingly, making sure to point out that the scope does not extend into external entities
2. Decide the current wording is sufficient.

Resolution: As in XB6, the editors are instructed to clarify the wording.

[XB9] XML Base is in conflict with RFC 2396

Source: MURATA Makoto http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0011.html

Summary: I think that XBase should prohibit default values for xml:base.

At present, a default value for the xml:base is allowed to appear in an external DTD subset or external parameter entitiy. Then, that default value would control all XML document entities that reference to this external DTD subset or external parameter entity. (BTW, as we are painfully aware, non-validating processors are allowed to ignore them!)

I think this is a violation of RFC 2396. It only allows a base URI for a MIME entity to be embedded in this very MIME entity, but does not allow embedding in different MIME entities.

RFC 2396 says:

---

5.1.1. Base URI within Document Content Within certain document media types, the base URI of the document can be embedded within the content itself such that it can be readily obtained by a parser. This can be useful for descriptive documents, such as tables of content, which may be transmitted to others through protocols other than their usual retrieval context (e.g., E-Mail or USENET news).

---

Possible decisions:

1. keep as is
2. Add a note saying that the default declaration may be inherited from a different Mime entity
3. Forbid default values for XBase

Resolution: 1/ but directing the editor to borrow wording from the namespace spec about warning about having such declarations in the external subset. the DOC should include a modified version of Steve's analysis.

[XB10] describe XML Base for comments ?

Source: Jonathan Marsh during Core telcon

Summary: should we describe XML Base for comments ?

I noticed (in looking at Infoset issues in the Core WG telcon) that XML Base    does not specify the base for URI References appearing in comments.  Do we      want to do anything about this?                                                                                                                                 pro) Yes.  For consistency, we should describe the base for URI References      everywhere they could appear in an XML document, and this includes comments.                                                                                    con) No.  The content of a comment is not interpretable as anything but         text, and cannot be recognized as a URI Reference.  XML Base therefore does     not apply.  Mentioning it would only encourage people to put processable        information inside comments which is abusive.

Possible decisions:

1. keep as is
2. make a note that comments have no XML Base
3. make a note that comment inherit their base from parent

Resolution: 1/ status quo.

[XB11] allowing non-absolute xml:base attribute values

Source: James Clark http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Aug/0007.html

Summary: should we allow relative URI in XML Base values

Allowing the value of xml:base to be relative seems like an unnecessary       
complication to be.  In HTML 4.0, a base URI specified by the BASE            
element is required to be absolute                                            
(http://www.w3.org/TR/html401/struct/links.html#edef-BASE). The               
Content-Base MIME header defined in RFC 2110 also requires an absolute        
URI. 

Possible decisions:

1. keep as is
2. forbid relative URI-References in XML Base values

Resolution: 1/ keep as is, XML Base doesn't do an exactly equivalent job as HTML BASE

[XB12] Ambiguity in XML Base

Source: James Clark http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Sep/0005.html

Summary: it is unclear whether one should first check for entity boundary or the parent Base

XML Base states:

  The base URI for a URI reference appearing in the content of 
  a processing instruction is the base URI of the parent element 
  of the processing instruction, if one exists, otherwise the 
  base URI of the document entity or external entity containing 
  the processing instruction.

James read this to mean that you check for parent elements first (crossing
external entity boundaries if necessary) and only if no parent exists do you
look for the containing entity.  This is not what we intended.  Here is a
clarifying phrase.

  The base URI for a URI reference appearing in the content of 
  a processing instruction is the base URI of the parent element 
  of the processing instruction, if one exists [+[within the 
  document or external entity]], otherwise the base URI of 
  the document entity or external entity containing the 
  processing instruction.

This clarification also is appropriate when describing xml:base attribute
treatment:

  The base URI for a URI reference appearing in an xml:base 
  attribute is the base URI of the parent element of the 
  element bearing the xml:base attribute, if one exists
  [+[within the document or external entity]], otherwise 
  the base URI of the document entity or external entity 
  containing the element.

Possible decisions:

1. keep as is
2. make the change suggested by Jonathan

Resolution: 2/ Change as recommended.