]>
XML Base Disposition of Comments NOTE-xmlbase-comments-&year;&MMDD; W3C Note &day;&month;&year; &XMLBaseDoC; &XMLBaseDoC; Jonathan Marsh Microsoft jmarsh@microsoft.com

This document is a Note of the W3C's XML Linking Working Group describing the disposition of comment as of June 7 2000 on XML Base first Last Call. It may be updated, replaced or rendered obsolete by other W3C documents at any time.

This document is a NOTE made available by the W3C for discussion only. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members.

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

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.

This document details the responses (or lack of response) made to issues in XML Base raised by the XML Linking Working Group, other W3C Working Groups, and the public (via the www-xml-linking-comments mailing list).

 English Februrary 23, 2000: Created.
Introduction

This document describes the disposition of comments in relation to the XML Base Last Call Working Draft. The comments have been categorized: technical errors in the current specification, requests from other Working Groups and Member Companies, and editorial comments (consisting of spelling and grammatical errors). Each issue is described by the name and contact information of the commentator, a description of the issue, and either the resolution or the reason that the issue was not resolved.

 Comments Received Technical Errors and Clarifications Why is XBase needed?

Source: Rick Jelliffe, &comments-list;/0046.html.

Rick proposes that the functionality of xml:base is already available in the form of XML entity references, <html:base>, and variables in XSLT transformations. Rick also is concerned by a lack of a Requirements document specifically for XML Base.

Resolution: Declined. Rationale follows:

The XML Base specification results from the attempt by the XLink group to fulfill it's requirements as found in the XLink Requirements Document. During development, it was determined that supporting something equivalent to the HTML BASE element was best provided generically to all URIs, instead of only those URIs which happened to be in xlink:href attributes. As a generic layer, it was felt that a separate namespace (xml) and a separate Working Draft would provide greater modularity.

XML Base was developed as a generic XML equivalent of html:base functionality. But in generic XML, we can't expect all hyperlinks to be represented as XLinks, neither do we expect URIs to appear only in hyperlinks. We favored consistently addressing the base problem at the URI level instead of the providing different base processing at the link level.

Layering XLink on top of XHTML, which in turn we hope will be layered upon XLink, is a bit circular.

Scoping of xml:base supports XInclude, which originated in the XLink group and is now being completed by the XML Core WG. Other applications which move subtrees of XML around or merge them can make use of xml:base to keep relative URIs from breaking with minimal intrusion into the document. The scoping behavior of xml:space and xml:lang was used as a model.

 "XBase" abbreviation is confusing

Source: Steve Hodgkiss, &comments-list;/0051.html. Also see linking issues list [XB2].

The term "XBase" previously referred to dBase, FoxPro, Clipper, et. al. as in the "XBase World" or "XBase Community". Unique terminology would be welcomed.

Editors comments: Defining a shortcut XBase for XML Base is of dubious value. We're only defining a single attribute, which is called "xml:base", not "x:base". We don't have XSpace or XLang. There is such a thing as taking the XWhatever naming convention too far.

Resolution: Accepted. Lose the acronyn XBase.

 XBase: unsetting the base URI

Source: Richard Tobin, &comments-list;/0066.html. Also see linking issues list [XB3].

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

Resolution: Declined, per the analysis at &comments-list;/0075.html.

 Clarify use over HTTP

Source: John Tigue, email to editor.

How about some explicit references to how this works over HTTP. Specifically, Section 14.11 entitled, "Content-Base" of RFC 2068 (which I notice doesn't appear in RFC 2616)?

This would follow the model of the xml-stylesheet spec: http://www.w3.org/TR/xml-stylesheet/

Resolution: Declined. The more recent RFC 2616 states in Section 19.6.3 entitled "Changes from RFC 2068":

Content-Base was deleted from the specification: it was not implemented widely, and there is no simple, safe way to introduce it without a robust extension mechanism.

Thus we defer to their judgment on what was widely implemented and would benefit from clarification in our spec.

 Scope of xml:base

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

Base is definition is circular, a relative base URI is resolved relative to the base URI.

Resolution: Duplicate of 2.1.6.

 relative base URI reference defined circularly

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

Base is definition is circular, a relative base URI is resolved relative to the base URI.

Suggested replacement text: "The value of the xml:base attribute denotes a URI with respect to the [base URI] property of the *parent* of the element on which it appears, provided the parent element starts and ends in the same external entity; otherwise (e.g. if the xml:base attribute occurs on the root element of a document) it denotes a URI with respect to the base URI of the enclosing external entity." And add an example of relative base URIs.

Resolution: Accepted.

 XBase is in conflict with RFC 2396

Source: MURATA Makoto, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0011.html. Also see linking issues list [XB9].

At present, a default value for the xml:base is allowed to appear in an external DTD subset or external parameter entity. Then, that default value would control all XML document entities that reference to this external DTD subset or external parameter entity. This is a violation of RFC 2396.

Options from this and subsequent threads include:

XML Base should prohibit default values for xml:base. XML Base should prohibit default values for xml:base in external DTDs. Add a note indicating that the base may be inherited from a different Mime entity. Do nothing - treat the use of an element type which defaults xml:base as sufficient indication within the document entity of the base URI.

Further investigation reported by Steve DeRose in RFC 2396 and BASE (member only), and reproduced here for convenience:

... I went and looked over 2396 in detail. For one thing, it says:

5.1.2. Base URI from the Encapsulating Entity If no base URI is embedded, the base URI of a document is defined by the document's retrieval context. For a document that is enclosed within another entity (such as a message or another document), the retrieval context is that entity; thus, the default base URI of the document is the base URI of the entity in which the document is encapsulated.

Now with XML Base, there is no unique meaning to the phrase "the base URI of the entity in which the document is encapsulated" -- because there may be many. It seems to me that the most reasonable interpretation of this clause in the face of that fact would be "the base URI [at the encapsulation point in] the entity in which the document is encapsulated -- that is, when an entity is included in another and the enclosing doc has multiple bases at different places, choose the one that's in effect at the relevant point ...

But perhaps most telling, check this out from section 5.1.1:

Protocols that do not use the MIME message header syntax, but which do allow some form of tagged metainformation to be included within messages, may define their own syntax for defining the base URI as part of a message.

XML is, in itself, a protocol that does not use MIME, but which allows tagged metainformation. So it may define its own syntax for defining the base URI as part of its "messages". "message" is a MIME term, and this paragraph is talking about MIME -- but isn't the best interpretation of "message" in XML terms, "document"? In which case, this clause appears to permit exactly what we want.

I couldn't find the constraint that's supposed to be there, that the BASE must be defined in the same MIME object. I examined every instance of "base", "MIME", and even "must" in RFC2396.... Can anyone else find it? Or perhaps were people thinking of the 5.1.1 text just cited, which does not seem to have any clear conflict with what we want.

Resolution: However, in light of these concerns, and despite the doubts raised by Steve, we will attempt to mitigate the problem. It seems impractical to enforce restrictions on where xml:base attributes may be declared, as some processors cannot be expected to have this information, and enforcement (or even ignoring such attributes) cannot be reliably performed without changes to XML 1.0 parsers. We note that Namespaces faces a similar problem (defaulting something as intrinsic to a document as the namespace declarations is unwise), and we will add a note to XML Base phrased along the same lines as appear in the Namespace rec, warning users not to engage in such practice.

 Requests From Other Working Groups and Member Companies I18N: scoped attribute support

Source: Martin J. Dürst, http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Mar/0020.html (members only). Also see linking issues list [XB4].

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 scarce if not non-existent. 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.

Resolution: Remove the sentences noting the similarity to xml:space and xml:lang as it does not add any normative value. I also note here that XPath has some facility for scoped attributes - ancestor-or-self::*[@xml:lang][1]/@xml:lang identifies the xml:lang attribute currently in scope.

 I18N: reference character model

Source: Martin J. Dürst, http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Mar/0020.html (members only). Also see linking issues list [XB5].

For URIs, RFC 2396 (URIs) is referenced directly, without taking the provisions of http://www.w3.org/TR/charmod/#URIs into account. This should be corrected.

Resolution: Accepted. Since the character model is still a working draft, it may be appropriate to copy the relevant text into XML Base to satisfy the request for normativeness, as suggested in http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Mar/0025.html (members only).

 I18N: scoping into external entities

Source: Martin J. Dürst, Thread starting at http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Mar/0020.html (members only). Also see linking issues list [XB6].

I18N asked us to clarify the difference between not extending into external entities and extending into external entities. After such an example was provided, Martin stated: "I think that things should work the other way from how they are specified now." In other words, xml:base SHOULD extend into external entities, one reason being that internal and external entities should be handled consistently.

Provide for the extension of base into external entities. Define (if XML 1.0 allows us to) that the base URI of elements in an internal entity are set to the base URI of the document entity. Thus entities would always carry their base independently of their context. Note the discrepancy and warn users about it.

Resolution: Option 3, note the discrepancy and warn users of it. Changes to support the extension of xml:base into external entities are declined for the following reasons:

Canonicalization already breaks things, so the existence of scenarios broken solely by this feature is dubious. The base would be context dependent when relative URIs are used, which would tend to be confusing and may cause unexpected behavior, e.g. broken links. See the concerns about the wisdom of this practice raised by the comment "XBase is in conflict with RFC 2396". Suggested behavior is inconsistent with the Infoset and the XPath Data Model.

Extending the scope into internal entities also is rejected, internal and external entities are used very differently by customers, and consistency here does not seem necessary. Infoset and possibly XPath would need to reflect this change - the costs are not justifiable.

 Schema: xml:base information item handling

Source: C. M. Sperberg-McQueen, &comments-list;/0081.html.

XML Schema depends on the infoset to carry information about xml:base declarations. Schema suggests three possible resolutions:

Make the xml:base available as a scoped information item similar to namespaces. Make the xml:base information available through convenient core properties on all relevant information items. Make the base URI information item mandatory (core) not optional (peripheral).

Resolution: Out of scope. This functionality has been moved to the Infoset. We believe they are adopting a solution along the lines of options 2 and 3.

 DOM: impacts of xml:base on namespaces

Source: Lauren Wood, &comments-list;/0085.html.

XBase makes the current ambiguity about relative URIs in namespaces more acute. As such the DOM recommends:

XBase should state clearly whether it should apply to namespace URIs or not. Don't consider XBase final until the interaction with namespaces is clarified. Clarify that making the relative URI absolute by using XBase still does not make it identical with an absolute namespace URI. Only the act of traversing a namespaceURI actually requires making the relative URI absolute. Don't expand the scope of the Infoset to XBase.

Resolution: The plenary has suggested that namespace names be compared as literal strings. See http://lists.w3.org/Archives/Member/w3c-xml-plenary/2000Apr/0222.html (members only). Accordingly, we concur with the first three points. The second last call draft addresses the need for more clarity on namespace issues. The last point is out of scope for this group as the Infoset is owned by the XML Core WG. They have resolved to support XML Base in the infoset. Notwithstanding this, it is our belief that the Infoset should incorporate XML Base processing, as it is closely correlated with the base URI property.

 DOM: is base contextual?

Source: Lauren Wood, &comments-list;/0085.html.

There seems to be scope for misunderstanding whether the base URI is a property of the information item and therefore moves with it when it is moved (as for namespaceURI), or whether it is contextual.

Resolution: out of scope. XML Base provides a way for a MIME entity of the XML Media type to specify a base URI per RFC 2396. The Infoset describes how the xml:base attribute interacts with the base URI property. As an infoset "property" it is implied that base URI must stay with information items when they are moved. Neither XML Base nor the relevant parts of the Infoset constrain APIs as to how they manage dynamic manipulation or serialization of an infoset.

 Core: XML Base like xml:space/xml:lang

Source: Paul Grosso, http://lists.w3.org/Archives/Member/w3c-xml-linking-wg/2000Apr/0048.html (member only). Also see linking issues list [XB7].

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.

Options from this and subsequent threads include:

Delete the last sentence of each referenced paragraph. Reword things to mention xml:lang and xml:space in such a way that there is no normative dependency. Leave worded as is.

Resolution: Option 1 accepted - delete references to xml:lang and xml:space.

 Core: XML Base scope

Source: Paul Grosso, http://lists.w3.org/Archives/Member/w3c-xml-linking-wg/2000Apr/0048.html (member only). Also see linking issues list [XB8].

There is no clear positive statement about the scoping of xml:base. We should add such to the spec.

Options include:

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. Leave worded as is.

Resolution: Option 1 accepted - describe scoping clearly.

 Spelling Errors and Other Typos Reference xml:lang and xml:space

Source: Susan Lesch, &comments-list;/0062.html.

2. par. 2 "...This enables scoping behavior consistent with the xml:lang and xml:space attributes." could give those attributes' source the first time they are mentioned. For example: This enables scoping behavior consistent with the xml:lang and xml:space attributes (defined in [XML] sections 2.12 and 2.10).

Resolution: Accepted.

Consistent name for XML namespaces

Source: Susan Lesch, &comments-list;/0062.html.

2. par. 3 and Appendix A list item 2 "XML Namespaces" could be the title "Namespaces in XML" or read "XML namespaces" (no cap).

Resolution: Accepted.

Use example.org in examples

Source: Susan Lesch, &comments-list;/0062.html.

2. example following par. 4, and the list that follows "http://somewhere.org" could read "http://example.org". IANA registered example.com, example.net, and example.org for just this kind of use. (See RFC 2606 also known as BCP 32 at http://www.ietf.org/rfc/rfc2606.txt.)

Resolution: Accepted.

Formatting of xml:base

Source: Susan Lesch, &comments-list;/0062.html.

Appendix A - list items 1 and 2 The plain instances of xml:base could read xml:base to match the others.

Resolution: Accepted.

use example.org

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

Replace somewhere.org with example.org.

Resolution: Duplicate of 2.3.3.