XML Base Disposition of Comments

xmlbase-comments-&year;&MMDD;

&day;&month;&year; &XMLBaseDoC; HTML XML http://www.w3.org/2000/06/xmlbase-comments-20000607 Jonathan Marsh Microsoft jmarsh@microsoft.com

This document of the W3C's XML Linking Working Group describes the disposition of comments as of &month; &day; &year; on the XML Base first and the second Last Call Working Drafts. It may be updated, replaced or rendered obsolete by other W3C documents at any time.

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

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 both the first and second Last Call Working Drafts. 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: 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.

"XBase" abbreviation is confusing

Source: Steve Hodgkiss, &comments-list;/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.

XBase: unsetting the base URI

Source: Richard Tobin, &comments-list;/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 &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: (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.

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.

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.

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:

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

Deployment strategy unclear (2nd last call)

Source: Larry Masinter, http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Jun/0056.html (members only).

When you say "Relative URIs appearing in an XML document" you need to be completely clear about:

Exactly which "XML documents" it applies to, since it clearly does not apply to any context in which XML appears.

Exactly which "relative URI references" it applies to, within those documents, since even for documents that are in scope, it does not apply to all possible strings which use the relative URI reference syntax.

Resolution: (members only) Accept. Add the following wording to the start of Appendix C:

XML Base defines a mechanism for embedding base URI information within an XML document. It does not define a mechanism to recognize which content or attribute values might contain URIs. This is only known by the specifications or applications assigning semantics to the vocabulary.

It is the intention of XML Base that future specifications and revisions of XML vocabularies identify which parts of the XML document are considered to be URIs, and provide normative reference to this specification in order to ensure that relative URIs are treated consistently across XML documents.

XML Base Conformance (2nd last call)

Source: J.R. van Ossenbruggen, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0083.html.

Unlike most other XML related specs, the XML Base draft is lacking a conformance section defining XML Base conforming documents and/or applications.

Is this an oversight?

Resolution: (members only) Add the following conformance statement; "An application conforms to XML Base if it calculates base URIs in accordance with the conditions set forth in this specification.".

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

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

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.

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: (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:

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

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

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

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:

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 (members 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:

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: (members only) Option 1 accepted - describe scoping clearly.

DSig: XML Base and XPath absolutizing of URIs (2nd last call)

Source: John Boyer, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0040.html.

The XPath Recommendation states that URIs are absolutized, but no mechanism for specifying the base URL is given. I need to know as soon as possible whether an erratum to XPath will be issued to state that XBase will be the way of doing it. Alternately, will there be an erratum stating that XPath does not absolutize URIs?

Options include:

Add XPath to appendix C. The default is that XML Base does not currently apply to the XPath data model.

Push off problem to XPath.

Do nothing.

Resolution: (members only) Option 1 and 2 accepted - describe XPath and XSLT impacts in Appendix C, and draft message on XSLT issue and forward to the XSL WG.

SYMM: comments on XBase (2nd last call)

Source: Lloyd Rutledge, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0068.html.

XBase as a recommendation fits into SMIL because SMIL is XML. We will not make any specific restrictions on the use of XBase with SMIL.

We request the SML Linking WG to consider adding referential XBase functionality to the current draft, or a later version. We will not make this a requirement for using XBase with SMIL, however.

If the XBase recommendation does not have referential functionality, then we may use XBase and add SMIL specific referential functionality to it.

Resolution: (members only) Declined. The proposal adds complexity and introduces many new issues. The necessity to include this feature in XML Base 1.0 is not clear.

I18N: Endless loop in relative xml:base attributes (2nd last call)

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

"Note that this applies to xml:base attributes themselves." The last sentence seems confusing if not completely wrong. It says to resolve the xml:base attribute against itself. This will lead to an endless loop. Please change.

Resolution: (members only) Accepted.

I18N: scoping into external entities part 2 (2nd last call)

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

Martin is unsatisfied with the resolution of the comment "I18N: scoping into external entities".

Resolution: (members only) Declined again. Rationale clarified:

Canonicalization has been notified of the problem, see http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0034.html.

There are concerns about the wisdom of this practice raised by the comment "XBase is in conflict with RFC 2396". In that case, we warn users against this practice, but they have to go out of their way to engage in it. In this case, users would engage in this practice unless they specifically added xml:base workarounds.

XML Core WG confirmed our behavior, see http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0056.html.

We note that Martin's suggested architecture is coherent and solves some problems, but is inconsistent with existing practice in XSLT, XML 1.0 and the infoset, and SGML. The practical costs of switching architectures at this point overwhelms the benefit of his architecture.

Martin is not satisfied with this resolution.

I18N: change "crosshatch" to "number sign" (2nd last call)

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

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

Resolution: (members only) Accepted.

HTML WG comment on XML Base (2nd last call)

Source: Steven Pemberton, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0005.html.

IE and Netscape follow RFC1808 in regards to handling of the relative URI "". XML Base follos RFC 2396.

Resolution: (members only) Declined. RFC2396 supercedes RFC1808. For XML Base to refer to RFC1808 instead would be bizarre. Part of supporting XML Base involves support for RFC 2396.

DSig: XML Base Comment (2nd last call)

Source: John Boyer, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0080.html.

XML base is restricted from applying to external entities. However, when you c14n a document, the external entity content is brought into the document, so xml:base will apply to it.

I think c14n is doing the right thing in that it is consistent with what xml:base should do: the entities are no longer external, so xml:base attributes from ancestors should apply to them.

Resolution: (members only) Duplicate of 2.1.12.

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

References suggestions (2nd last call)

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

XML is a normative reference, but not linked to in the text until Appendix C. You might spell out the specification's name "Extensible Markup Language (XML) 1.0 [XML]" with a link to #XML the first time it is mentioned in the introduction.

Also for C., e-commerce markup uses a "baseurl" [2] that may or may not be related to XML Base; (I don't know).

Resolution: (members only) Accept. The micropayment spec is not relevant because it does not specify an XML grammar - just HTML and RDF representations, neither of which are in scope for XML Base.

Spelling errors (2nd last call)

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

2. par. 2 and C. list item 3 could spell out "spec" as "specification."

There are missing space characters in 4. last par. "NOTE:The" and in A. Unicode "Standard.(See".

In B. XHTML, "et. al." should read "et al."

Resolution: (members only) Accept.

Wording issue (2nd last call)

Source: Paul Grosso, http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0064.html.

In section 4 [1], the third point of the summary of RFC 2396 says: "The base URI is that of the URI used to retrieve the entity. ... Therefore, the words "that of" should be struck in our summary of point 3.

Resolution: (members only) Accept.