List and dispositions of issues recorded against the third XInclude Candidate Recommendation.
This document is a live document and can change at any time, in particular to update the status of issues may change over time (hopefully for the better).
Color key: error warning note
| Id:Title | State | Type | Ack. |
|---|---|---|---|
| xi-0 : Language attributes | declined | request | No reply from reviewer |
| xi-1 : Fragment identifiers must not be used. | declined | clarification | No reply from reviewer |
| xi-2 : Syntactically incorrect IRIs in href attributes | declined | clarification | Objection |
| xi-3 : Re: XML Schema WG Comments on Last Call Draft | declined | editorial | Agreement |
| xi-4 : examples of xpointer attribute use | agreed | editorial | Agreement |
| xi-5 : Handling unrecognized xpointer schemes | agreed | editorial | No reply from reviewer |
| xi-6 : xml:lang="" | declined | editorial | No reply from reviewer |
| xi-7 : xml:lang when replacing the root element | agreed | editorial | No reply from reviewer |
| xi-8 : Case insensitive comparison of xml:lang values | agreed | error | No reply from reviewer |
| xi-9 : Editorial: must not vs. fatal error | agreed | error | No reply from reviewer |
| xi-10 : URIs that end in # but don't have fragment IDs | agreed | clarification | Agreement |
| xi-11 : minor remark regarding appendix c | agreed | editorial | No reply from reviewer |
| xi-12 : xml:lang implementation report | declined | request | Objection |
I understand the point of the language retention in the new draft. I haven't implemented it yet, but I don't expect it to be too hard. I'm not sure how useful this will be in practice, but it doesn't feel like it will hurt too much. I do wonder, however, why you felt it necessary to add a new Infoset property here? Unlike the included sets property, this is not directly related to the functionality of XInclude. It is something that could have been added to the original Infoset spec, and wasn't. Sneaking it in here doesn't feel right. There are a few of other issues with this: 1. As far as I know no API or tool provides specific support for this. i.e. there's no getLanguage call in DOM, or XOM, or XSLT. Everyone just reads the xml:lang attributes if they need to know this. 2. Adding language as an infoset property in addition to the xml:lang attribute opens up the possibility that these could get out of sync. That's a big enough problem in the Infoset already without adding to it here. I suggest simply removing all the verbiage about the [language] property and simply defining this in terms of an xml:lang attribute information item. I don't think this would have any practical affect on implementations, but it would make the spec smaller, simpler, and cleaner.
Section 3.1 states, "Fragment identifiers must not be used" (in URIs in href attributes. OK. However, what happens if one is used? Is this a fatal error? Should the processor just ignore it? I think this should be spelled out. I think my preferred solution would be a non-fatal error. IN fact, maybe this should instead read something like. "XInclude processors must not use the fragment identifier in the uRI if one is present."
Add something along the lines of: "syntactically invalid IRIs should be reported as a fatal error, but in some implementations it may not be practical to distinguish it from a resource error."
I wish there were a publicly accessible issues list/bug database, because I could swear I've raised this before; but looking through the archives I don't find it. What should a processor do in the case where the href attribute contains a string which is not a legal IRI reference? For instance, it includes bad hexadecimal escape sequences? In particular is this a resource error or a fatal error? I don't find any language in the current CR that's clearly on point. I suspect this is covered under: Resources that are unavailable for any reason (for example the resource doesn't exist, connection difficulties or security restrictions prevent it from being fetched, the URI scheme isn't a fetchable one, the resource is in an unsupported encoding, or the resource is determined through implementation-specific mechanisms not to be XML) result in a resource error. Resources that contain non-well-formed XML result in a fatal error. But I'm not sure. Clarification in the spec would be useful. Consistency with XPointer syntax errors, which are recognized as resource errors, also suggests these should be resource errors.
Add something along the lines of: "syntactically invalid IRIs should be reported as a fatal error, but in some implementations it may not be practical to distinguish it from a resource error."
> From: Jonathan Marsh <jmarsh@microsoft.com> > Date: Mon, 29 Mar 2004 13:19:48 -0800 > To: "C. M. Sperberg-McQueen" <cmsmcq@acm.org> > Cc: "Ashok Malhotra" <ashokma@microsoft.com>, <www-xml-xinclude-comments@w3.org>, <w3c-xml-schema-ig@w3.org> > > The XML Core WG has accepted your request to provide a place for the > xi:include elements in the resulting infoset. Here is a draft of the > significant part of the text I'm proposing to replace the Boolean > [included] property: > > -------------- > The inclusion history of each top-level included item is recorded in the > extension property [include history]. The [include history] property is > a list of element information items, representing the xi:include > elements for recursive levels of inclusion. If an [include history] > property already appears on a top-level included item, the xi:include > element information item is prepended to the list. If no [include > history] property exists, then this property is added with the single > value of the xi:include element information item. > -------------- > > We note that we don't expect to see implementation fully exposing this > property in our upcoming CR, but that's no worse a match with current > implementations than the previous [included] property. Thank you for your reply to our further request [1], we appologize for the delay in responding. The working has discussed this response and are happy with the result. Some members of the WG noted, however, that the term "already" in the sentence "If an [include history] property already appears on a top-level included item..." above implies a time axis in the construction of the result infoset. That is, if a includes b includes c, which include happens first? We appologize if this aspect is covered elsewhere in the XInclude CR [2] but a quick perusal of section 4 Processing Model [3] did not turn anything up. While it is not necessary to address the above in order to satisfy the Schema WG in response to our previous comments you might want to consider addressing it to prevent future questions of this nature. thank you, pvb (for the XML Schema WG) [1] http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2004Feb/0021.html [2] http://www.w3.org/TR/2004/CR-xinclude-20040413 [3] http://www.w3.org/TR/2004/CR-xinclude-20040413/#processing p.s. For the record, our original comment on the Last Call is here [4] and your response to that comment is here [5] [4] http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2004Jan/0015.html [5] http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2004Feb/0011.html
It would be _very_ helpful to see examples which use the normative XPointer mechanisms, i.e. shorthand pointers and element() scheme pointers.
I've probably said this before, but as there's no publicly accessible issues list and I don't see it in the archives, so I'll say it again in case I haven't. The current candidate rec is insufficiently clear on what an implementation should do when encountering an unrecognized XPointer scheme in an xpointer attribute, and there's no additional recognized XPointer scheme to fall back on. In my case thie issue is xpointer() schemes, but it could also be xpath1() scheme or other custom schemes. Is this a resource error? a fatal error? Should the processor simply ignore the xpointer attribute? The spec says, "A syntax error in the XPointer is a resource error <http://www.w3.org/TR/xinclude/#dt-resource-error>." However, this is not a syntax error, even though it is an error according to section 3.3 of the XPointer framework.
I'm working on implementing xml:lang handling in XOM for XInclude. One thing strikes me as very funny. Suppose I have a document written in English that uses xml:lang="en" on its root element. Suppose this document includes another doucment also written in English that does not, however, use any xml:lang attributes. The inclusion process will create lots of unnecessary and indeed misleading xml:lang="" attributes. This seems unnecessarily confusing. Furthermore, the addition of extra xml:lang attributes in unpexpected places may mess up validation, since most schema languages require these attributes to be declared like any others. I still prefer giving no special treatment to xml:lang compared to any other attribute. -- Elliotte Rusty Harold
Section 4.5.6 of the CR states: Each */element information item/* in the top-level included items <http://www.w3.org/TR/xinclude/#dt-top-level-included-items> which has a different value of *[language]* than its include parent <http://www.w3.org/TR/xinclude/#dt-include-parent> has an */attribute information item/* added to its *[attributes]* property. This attribute has the following properties: What if the include parent is a document, not an element? in other words, what if the root element is an xi:include element? The current language suggests that no xml:lang attribute would be added in this case, but I doubt that's the intent.
This is an important point but one that's easy to fix. According to RFC 3066, language "tags are to be treated as case insensitive; there exist conventions for capitalization of some of them, but these should not be taken to carry meaning." However, this is not consistent with language fixup in the XInclude CR which states, "Each element information item in the top-level included items <http://www.w3.org/TR/xinclude/#dt-top-level-included-items> which has a different value of [language] than its include parent <http://www.w3.org/TR/xinclude/#dt-include-parent> has an attribute information item added to its [attributes] property" This should be rewritten to make it clear that this comparison is case insensitive. fr-ca and FR-CA are the same thing, for example.
Section 3.1 states:
Fragment identifiers must not <http://www.w3.org/TR/xinclude/#dt-must>
be used.
However, section 6.2 states:
An application conforms to XInclude if it:
*
supports [XML 1.0] <http://www.w3.org/TR/xinclude/#XML>,
[Namespaces in XML] <http://www.w3.org/TR/xinclude/#XMLNS>, the
[XML Information Set] <http://www.w3.org/TR/xinclude/#XMLIS>, [XML
Base] <http://www.w3.org/TR/xinclude/#XMLBase>, the [XPointer
Framework] <http://www.w3.org/TR/xinclude/#XPCore>, and the
[XPointer element() scheme] <http://www.w3.org/TR/xinclude/#XPElement>
*
stops processing when a fatal error
<http://www.w3.org/TR/xinclude/#dt-error> is encountered.
*
observes the mandatory conditions (must
<http://www.w3.org/TR/xinclude/#dt-must>) set forth in this
specification, and for any optional conditions (should
<http://www.w3.org/TR/xinclude/#dt-must> and may
<http://www.w3.org/TR/xinclude/#dt-must>) it chooses to observe,
observes them in the way prescribed
*
performs markup conformance testing according to all the
conformance constraints appearing in this specification.
It seems to me that "must nots" and musts are intended to apply to
processor behavior, whereas fatal errors normally describe document
content. If this interpretation is correct, I think the "must not" in
3.1.1 should instead be a fatal error. e.g.
It is a fatal error if a fragment identifier is used in the value of an
href attribute.
If my interpretation of section 3.1 is not correct, and this is not a
fatal error, then I would request that the spec further elaborate on
what implementations are supposed to do when encountering a fragment ID
in an href attribute.
As I read RFC 2396, in a URI such as http://www.example.com/index.xml#name the fragment identifier is "name". The sharp sign is not included in the fragment ID. Section 3.1 of the XInclude CR says that fragment IDs must not be used in href attributes. However, is this legal? <xi:include href="http://www.example.com/index.xml#"/> My current reading of the spec is that this is legal. But should it be?
hello. in the xinclude cr document, appendix c uses the phrase "The infoset resulting from resolving inclusions on this document is the same as that of the following document" for examples 1 through 4. as i understand it, the [language] property is optional, but the [include history] property is mandatory. so, technically speaking, the infoset of the serialization is not the (exact) same as that of the resolved inclusion. at least that's what i think...
Implementing the handling of xml:lang according to the latest CR is proving to be much more painful than I expected. It's doable, but it's going to require some nasty hacks. The big problem seems to occur whenever the XPointer implementation is decoupled from the XInclude implementation. The XInclude implementation knows what the current language is into which the nodes will be embedded but the XPointer implementation probably does not know this. Therefore the XPointer implementation cannot decide whether or not to add an xml:lang attribute to the nodes it returns because it doesn't know whether or not these are redundant. It might be a little easier to implement if the the XInclude implementation were allowed to add redundant xml:lang attributes rather than only ones that changed the language in effect. But overall, I'd really just prefer this language annotation to be dropped completely.
Last update: $Date: 2004/09/17 15:53:54 $
This page was generated as part of the Extensible Issue Tracking System (ExIT)
Copyright © 2003, 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.