XML Base Disposition of Comments

2.1.1. Why is XBase needed?

Source: Rick Jelliffe, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/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 (members only): 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.

2.1.2. "XBase" abbreviation is confusing

Source: Steve Hodgkiss, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0051.html. Also see linking issues list [XB2] (members only).

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 (members only): Accepted. Lose the acronyn XBase.

2.1.3. XBase: unsetting the base URI

Source: Richard Tobin, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0066.html. Also see linking issues list [XB3] (members only).

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 (members only): Declined, per the analysis at http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0075.html.

2.1.4. 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 (members only): 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.

2.1.5. 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 (members only): Duplicate of 2.1.6.

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 (members only): Accepted.

2.1.7. 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] (members only).

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:

1. XML Base should prohibit default values for xml:base.
2. XML Base should prohibit default values for xml:base in external DTDs.
3. Add a note indicating that the base may be inherited from a different Mime entity.
4. 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 (members only): 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.

2.2.1. 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] (members only).

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 (members only): 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.

2.2.2. 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] (members only).

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 (members only): 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).

2.2.3. 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] (members only).

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.

1. Provide for the extension of base into external entities.
2. 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.
3. Note the discrepancy and warn users about it.

Resolution (members only): 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:

1. Canonicalization already breaks things, so the existence of scenarios broken solely by this feature is dubious.
2. 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.
3. See the concerns about the wisdom of this practice raised by the comment "XBase is in conflict with RFC 2396".
4. 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.

2.2.4. Schema: xml:base information item handling

Source: C. M. Sperberg-McQueen, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0081.html.

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

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

Resolution (members only): 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.

2.2.5. DOM: impacts of xml:base on namespaces

Source: Lauren Wood, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0085.html.

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

1. XBase should state clearly whether it should apply to namespace URIs or not.
2. Don't consider XBase final until the interaction with namespaces is clarified.
3. 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.
4. Don't expand the scope of the Infoset to XBase.

Resolution (members only): 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.

2.2.6. DOM: is base contextual?

Source: Lauren Wood, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/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 (members only): 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.

2.2.7. 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] (members only).

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:

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 (members only): Option 1 accepted - delete references to xml:lang and xml:space.

2.2.8. 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] (members only).

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

Options include:

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

Resolution (members only): Option 1 accepted - describe scoping clearly.

2.3.1. Reference xml:lang and xml:space

Source: Susan Lesch, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/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 (members only): Accepted.

2.3.2. Consistent name for XML namespaces

Source: Susan Lesch, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/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 (members only): Accepted.

2.3.3. Use example.org in examples

Source: Susan Lesch, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/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 (members only): Accepted.

2.3.4. Formatting of xml:base

Source: Susan Lesch, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0062.html.

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

Resolution (members only): Accepted.

2.3.5. 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 (members only): Duplicate of 2.3.3.