XML Inclusions (XInclude) Issues List

Dummy issue used to record the next unused issue number.

Do we want to note that the inheritance of xml:space and xml:lang are not preserved, and warn users that this information may be invalidated by inclusion?

Resolution (see - W3C Members only):

Yes, add such a note.

Do we want to note that properties asserting conditions about descendants may be invalidated by the inclusion process? Specifically the validation attempted PSV property comes to mind.

Resolution (see - W3C Members only):

Yes, add such a note.

Should we update the namespace URI to distinguish between WDs and the expected CR/PR/Rec? If so, at what point should we switch? Before last call?

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2001AprJun/0088.html - W3C Members only):

Yes, get a new namespace for the last call.

I believe there should be a way to include octet-stream objects into XML documents. A simple approach would be to add a new value of the "type" attribute, namely "base64". [John Cowan: http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2001JanMar/0283.html (members only)]

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2001AprJun/0037.html - W3C Members only):

Don't add this for 1.0. The use cases do not seem to involve transmitting across the internet which lowers its priority. Some compelling use cases might cause us to revisit this.

The resolution to issue 72 (illegal characters) does not meet the objection. The resolution says that a resource containing an illegal *byte sequence* causes failure. Issue 72, however, is about illegal *characters* that are correctly encoded. Suggested resolution - add the sentence "Characters that are not permitted in XML documents also cause the inclusion to fail." [John Cowan: http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2001JanMar/0283.html (members only)]

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2001AprJun/0037.html - W3C Members only):

Accepted.

Do wre mandate a normalizing transcoder when switching encodings per the Character Model?

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2001AprJun/0105.html - W3C Members only):

I18N concluded that the question is irrelevant for parse="xml" since the infoset being merged in comes from an XML parser that supposedly has already dealt with the normalization issue. For parse="text", it is the XInclude processor which builds the infoset and we interpret the building of the infoset from a text entity in a legacy encoding as transcoding from the legacy encoding to UCS. Consequently, the requirement that "Recipients which transcode text data from a legacy encoding to a Unicode encoding form MUST use a normalizing-transcoder." (CharMod section 4.3) applies.

How are notation lists handled? Merged? What about duplicates?

Options:

1. Leave [notations] and [unparsed entities] in the result document undefined. Implementations would be free to do whatever they want with these properties, e.g. merge them, keep the original document's items, or simply discard them.

2. Leave [notations] and [unparsed entities] in the result document undefined, but constrained to specific alternatives, namely, it can merge them using some application-defined mechanism, or it can keep the items from the original document. Other types of manipulations would not be allowed.

3. Add any notation or unparsed entity referred to by a [references] property to the [notations] or [unparsed entities] properties. Duplicates (same name, same URI) are removed. Name conflicts may result (same name, different URI), in which case we warn people that [references] must be used to disambiguate, and that the result may require some application-specific cleanup (such as renaming) during serialization.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2001AprJun/0037.html - W3C Members only):

Option 3, with the additional caveat that applications may be able to detect and treat as duplicates notations with different literal property values.

Suggests the scope of XInclude should be expanded to cover all the functionality of entities. [Ray Witmer: http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2001Mar/0003.html]

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2001AprJun/0037.html - W3C Members only):

Do nothing. This proposal is beyond the scope of what we want to do in XInclude 1.0. We may wish to consider it for a possible future version of XInclude or perhaps another spec.

This could be considered as infoset corruption. Do we want to do some fixup so that inclusion is transparent? Our own Infoset Conformance section appears to say that we "should" do so...

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2001AprJun/0037.html - W3C Members only):

We currently have a note to this effect, but Jonathan will elaborate on it.

Do we need to normalize per the Character Model?

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2001AprJun/0105.html - W3C Members only):

I18N concluded that the XInclude processor should check normalization and fail if the input is not normalized (except that recipients that accept being insecure may assume normalization instead).

Is the encoding attribute always ignored when parse="xml"?

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2001JanMar/0385.html - W3C Members only):

Nothing is required, the encoding attribute has no use when parse="xml".

[Linda Welsh] I have a question about what xinclude processors (like a browser) actually handle xinclude elements. I know that the XInclude processor will perform the necessary substitution when it encounters an xinclude element at page load time, but what I'm wondering is what happens if I add an xinclude element to the DOM using script, after the document is loaded? Is it the expectation that a browser, in response to having an xinclude element added to its DOM, will actually add the contents of what the xinclude refers to, into the DOM, not an actual xinclude element? That is, is the power of XInclude is available in dynamically, just as it is at load time?

What I'm interested in doing is exploiting xinclude in a declarative event handler. For instance, it would be powerful if a "replace" handler could take a targetID (the thing being replaced), and a URI (what to replace it with), and when the handler gets invoked, it removes everything in the target element's content model, and just sticks in an xinclude element as its contents. Xinclude does the rest.

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

Specifics of dynamic behavior are out of scope. XInclude tells you how to do the inclusion, not when, which is left up to implementations.

Should the Syntax section come before the Processing Model to eliminate forward references?

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

Editorial.

How should characters out of the XML range i.e. production [2] http://www.w3.org/TR/REC-xml#charsets be handled? [Daniel Veillard http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2000Nov/0013.html].

Options:

1. Accepting them looks really bad, we would get an Infoset with chars out of the range accepted by XML.

2. Dropping the full text include is a reasonable option, but how many times are we gonna loose the full include due to a misplaced BEL or BS.

3. Dropping the out of range chars from the resulting infoset seems an even better option.

4. Replacing the out of range characters with some other character.

5. Leave unspecified.

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

Byte sequences outside the range allowed by the encoding cause the inclusion to fail.

What is our versioning strategy? Do we need features now, for example a version attribute, to enable XInclude 2.0?

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

We will not add a version attribute. We will say that unrecognized attributes on the include element are simply ignored. We will plan to use the namespace mechanism for any other versioning we may have to do.

URIs accessed at different times (say, during an "XInclude run" on two identical include elements in the same document) may produce different results. Do we need to say anything about this?

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

No. This is out of scope.

What is the behavior of fragments for non-XML resources? Do we ignore fragments which aren't XPointers or do we throw an error?

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2001JanMar/0319.html - W3C Members only):

No change - staying we interpret fragments as XPointers is fine.

When are XPointers allowed? When the resource is of type text/xml or application/xml? Or when parse="xml"?

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

When parse="xml".

When a document is fetched using HTTP, it may have an encoding value in the HTTP header. When a document that is fetched by that or any other means is an XML document, it may (but need not) contain an <?xml?> declaration specifying an encoding. But if a document is fetched by nfs:, afs:, file:, ftp:, and does not contain an <?xml ... encoding='...'?> declaration or is to be included as text, what encoding does it use?

There is a clear need for xinclude:encoding The value of this attribute is an EncName as defined in XML 1.0 spec., section 4.3.3, rule [81], specifying how the resource is to be translated. [http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2000Jul/0021.html]

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

First, use the externally specified encoding. If none exists, see if the document is text|application/xml|*+xml. If so use the encoding of the file. Otherwise, use the value of the encoding attribute, if one exists. Otherwise, assume UTF-8.

This seems a bit untrue. Should we define a new type of entity instead of reusing an old one?

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

Entities are gone, this issue is irrelevant.

As part of the return to element syntax, I re-introduced the ID attribute. Is this OK?

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

No. Remove the ID attribute to keep things minimal.

http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2000Aug/0000.html: If xinclude:parse is optional, please be more explicit about what the default value is (now it's only specified in the DTD fragment).

Suggested resolution: Add 'When omitted, the value of "xml" is implied (even in the absence of a default value declaration). Values other than "xml" and "text" are errors.'

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

Accept suggested resolution.

If we preserve the in-scope namespaces property, we may encounter the situation where an element has fewer in-scope namespaces than its parent. There is no syntax for "undeclaring" namespaces. If a result infoset is serialized and then reparsed, it will not be identical to the original result infoset. On the other hand, it is unlikely (impossible) that any of the extra in-scope namespaces will actually be referred to within the included context. Are there any situations where this information is harmful?

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

We could not detect any situations where this information would be harmful.

How is the encoding determined for text? We don't want to look inside the text for a format-specific indication. Is it adequate to state "This property is derived from a MIME header"?

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

Encoding is determined as described elsewhere.

Do we wrap this in a document entity to preserve base URI and charset? What is the relationship between the document information item and the document entity? The minimal infoset doesn't have to have a document entity.

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

No. Entities are gone.

The Infoset does not provide for whitespace outside the document element to be preserved. Accordingly, this whitespace will be stripped by XInclude. If this isn't desirable, the Infoset will have to make provision to expose the whitespace.

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

Note that such insigifnicant whitespace is lost.

This reuses the definition of 'include location', which is both absolutized and canonicalized. We previously decided only absolutization was necessary. Is character escaping harmful in this case? It simplifies the spec...

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

Editorial.

This implies the use of a non-validating parser, or at least makes no provision for surfacing of validation errors. Is this underspecified?

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

This should be addressed by a processing model, and as such is currently overspecified. Remove any prohibitions on how the infoset is acquired, and instead just talk about acquiring infosets. Consider adding a note that this is intentionally unspecified to allow future specs leeway in this area.

In section 3.1 you state that internal xpointer references must be resolved against the original source document. That's not so hard to do in DOM (though expensive if you do it merely by cloning the original document) but I think it's going to be quite tricky to do it in SAX. [Donald Ball http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2000Jul/0014.html].

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

Unfortunate, but this is a consequence of the expressive power of XPointer.

You don't state (as far as I could tell) what should happen to doctype nodes in included documents. [Donald Ball http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2000Jul/0014.html].

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

Spec states that doctype nodes are tossed.

But it occurs to me that if entity start/ends are preserved by xinclusion, then dummy entity start/end items should be inserted around the included nodes to ensure that they are balanced (in the same way that unbalanced element structure gets fixed up). [Richard Tobin: http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JulSep/0017.html (W3C Members only)]

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

Entity markers, CDATA markers, and include markers have been removed.

Previous working drafts employed an element in the XInclude namespace as an include element. This draft employs an attribute-based syntax. The WG plans to revisit this issue and encourages public input on this issue.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JulSep/0247.html - W3C Members only):

Return to element syntax.

Presumably a URI reference for an include with parse="text" should not be allowed to contain a fragment (xpath), since there is no infoset, just a collection of character items. Or do we want to allow ranges of characters from a text file? This seems be getting into the same area as infosets-from-external-entities.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JulSep/0372.html - W3C Members only):

When parse=text (regardless of the media type of the retrieved resource), we will treat the resource as text/plain and therefore the fragment id is as defined by the text/plain media type. Note: since currently there is no defined fragment id syntax for the text/plain media type, it is (currently) an error to have a fragment identifier when parse=text.

We specifically say that the namespace name property of an element is preserved when the infosets are merged. What about the in-scope namespaces property? This seems to be needed so that qnames in the included nodes can be resolved. What about the "declared namespaces" property? More generally, should there be a list of infoset properties that must be preserved or deleted?

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

Add text that everything is copied through unless otherwise specified.

Should there be a syntax for turning off nested inclusions? In some cases this can be used as an optimization hint.

Options:

1. Provide a switch for turning nested inclusions on and off.

2. Provide a switch used to assert that nested inclusions need not be performed to acheive the correct result.

3. Provide no such switch.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000AprJun/0474.html - W3C Members only):

Option 3 - nothing.

XInclude currently incompletely defines a processing model for dealing with inclusions in destination documents. This does not appear to be sufficient, and is opened by issue #3.

Options:

1. Create an XML Processing model that defines the interactions between some or all of XInclude, XPointer, XML Schema, DTD validation, XSLT, XML Query, XML Packaging and URI references.

2. Specify nothing about an XML Processing model. XInclude does not say whether destination documents are knitted before or after inclusion.

3. Specify a minimal subset of the XML Processing model necessary for XInclude. Destination documents are included after they have had their xincludes processed. There is no mention of the relationship between xinclude and other infoset to infoset transformations, ie XML Schema, XSLT. [David Orchard preference].

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000AprJun/0474.html - W3C Members only):

Option 3. This says that the xinclude model is expansion "as if" the included document has had all its xincludes expanded (in a "bottom up" fashion).

Do requirements belong in this document any longer?

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JulSep/0010.html - W3C Members only):

Remove them from this doc and point to the requirements in the NOTE (which haven't changed).

There is no need for the id attribute in the attribute-based syntax. OK to drop it?

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000AprJun/0443.html - W3C Members only):

ID attribute dropped.

Do we also want to accept external entity files, e.g. documents with more than one top-level element? If so we should make this clear.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JulSep/0010.html - W3C Members only):

No, we will not define an infoset for an external entity. Editor to add some wording pointing this out.

(Oh no not again!) Is the literal value of the URI Reference compared, or its absolutized and escaped version?

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JulSep/0173.html - W3C Members only):

We need to absolutize (but not canonicalize) URIs to detect infinite loops.

It is easy to see how to fail a non-xml resource - it's not well-formed. Is there a similarly well-defined mechanism for determining the success of a parse="text" inclusion? Or do we need to rely on the media type text/*? (We intentionally don't rely on text/xml, as we want to enable things like image/svg.)

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

Byte sequences outside the range allowed by the encoding cause the inclusion to fail.

We could preserve this information rather trivially, by describing an Infoset addition. For instance, a property [include-element] defined to contain the element information item for the include element in the original infoset. Applications unaware of this property would treat the inclusion as transparent, applications aware of this property could use it to (e.g. editors) switch between included and non-included "views" of the document. I don't see any harm in providing such an optional property.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JulSep/0173.html - W3C Members only):

Accept Jonathan's proposal.

Is such a normative reference to the Infoset "core" appropriate? In sync with language in the Infoset?

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JulSep/0010.html - W3C Members only):

Closed as subsumed by issue 52.

Earlier versions stated that "An XInclude processor must be able to merge documents in any mix of encodings that they would otherwise support in isolation." This doesn't make sense on the infoset level. Do we want to enforce this in some other way?

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000AprJun/0443.html - W3C Members only):

No. Issue dropped.

XLink specifies a conformance constraint that an application must "performs markup conformance testing according to all the conformance constraints appearing in this specification." Should XInclude include a similar constraint?

Options:

1. yes, add this as a conformance criterion.

2. no.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000AprJun/0443.html - W3C Members only):

Option 1 - Yes.

Do we add an optional id attribute (in the xinclude namespace) to the xinclude element? If not, what if anything do we say about id attributes on xinclude elements? [Subissue of XInclude30 http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0424.html (W3C Members only)]

Options:

1. add an optional attribute named "id"

2. don't, users who want ids must place it in a different namespace

Resolution (see #XInclude-29-add-id-attribute - W3C Members only):

Duplicate.

What if anything do we say about allowing xmlns "attributes" on xinclude elements? [Subissue of XInclude30 http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0424.html (W3C Members only)]

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0424.html - W3C Members only):

Nothing need be said, but we leave it to the editors to decide just what/how to say in this area.

What if anything do we say about not allowing unprefixed attributes on xinclude elements? and do we require an error message for such? [Subissue of XInclude30 http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0424.html (W3C Members only)]

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0424.html - W3C Members only):

We will say that unqualified attributes not explicitly mentioned in the xinclude spec are not allowed (but conforming implementations need not check for such and issue error messages).

What if anything do we say about allowing other attributes from other namespaces on xinclude elements? [Subissue of XInclude30 http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0424.html (W3C Members only)]

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0424.html - W3C Members only):

We will say that qualified attributes are allowed.

The infoset exposes entity information items http://www.w3.org/TR/xml-infoset/. XInclude does not define whether entity information items are copied via the infoset or not.

Options:

1. Leave unspecified.

2. Specify that entities are copied from infoset to infoset.

3. Specify that entities are not copied from infoset to infoset.

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

Entity have been removed.

It is unclear whether this is necessary. The CDATA start and end markers can be inserted around the include, and since the resource is acquired as text, there isn't really any necessity to double escape these. In any case the normative description should be worded in terms of CDATA markers.

Options:

1. allow multiple cdata sections to result from the include

2. preclude multiple cdata sections from resulting from the include

3. make it implementation-dependent

4. don't say anything - this is a serialization issue

5. do nothing - bogus issue

6. drop parse="cdata" making this issue obsolete

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000AprJun/0402.html - W3C Members only):

Option 6: remove parse="cdata".

The above implies one way to split a CDATA section into parts, but other ways exist, e.g. splitting ]-]> instead of ]]->. Do we want to mandate a specific split point?

Options:

1. yes, mandate a specific splitting algorithm

2. no, indicate that this is implementation-specific

3. leave it vague

4. drop parse="cdata" making this issue obsolete

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000AprJun/0402.html - W3C Members only):

Option 4: remove parse="cdata".

XInclude requires an XML element. This has implications for re-use in other vocabularies. It may be advantageous to have an attribute only syntax for XInclude to allow vocabularies the ability to create their own include elements. XLink, faced with a similar problem, chose to only support an attribute-based syntax.

Options:

1. add an an attribute-based syntax variant

2. provide only an attribute-based syntax

3. do nothing

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000AprJun/0402.html - W3C Members only):

Option 2: move to attribute-based syntax.

Currently, it is not possible to set the value of an attribute through an include mechanism. This make it difficult to generate XLinks for example. Should a mechanism be developed to include text as attribute values?

source:
  <x>
    <uri>theUri</uri>
    <link xmlns:xlink="...">
      <xinclude:include href="#xpointer(x/uri/text())"
         as-an-attribute-named="xlink:href"/>
    </link>
  </x>
result:
  <x>
    <uri>theUri</uri>
    <link xlink:href="theURI" xmlns:xlink="..."/>
  </x>

Options:

1. Develop a proposal along the lines of the example above. (Editors recommendation)

2. Develop some other mechanism to provide this functionality.

3. Don't provide this capability. (status quo)

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0424.html - W3C Members only):

Option 3. The syntax is messy. Is it really a requirement to be able to "include into" the value of an attribute? You can't do that with XML 1.0 and (external) entity references. No clear use cases.

The authors suggest that the xml: namespace should be the namespace of the include element. The use of the xml: namespace allows all xml documents to reference the inclusion mechanism without requiring additional namespace declarations to support inclusion. As inclusion is useful to most or all xml vocabularies, we suggest that it is reasonable to add to the xml: namespace.

Steve Rowe's feedback on this issue.

Options:

1. keep a separate namespace

2. use the xml namespace. (Editors recommendation)

Resolution (see http://www.w3.org/XML/Group/2001/03/xml-f2f-minutes - W3C Members only):

Keep a separate namespace.

Should the permission to add non-XInclude attributes such as ID be made explicit? [John Cowen in http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0292.html (W3C Members only)]

Options:

1. Make the permission to add non-XInclude attributes explicit. (Editors recommendation)

2. Revoke permission to add non-XInclude attributes.

3. The permission to add non-XInclude attributes implication is adequate.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0424.html - W3C Members only):

Split into a number of subissues (37,38,39,40).

Should an id attribute be added to XInclude? If so, how is it given the ID datatype? [Paul Grosso in http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0290.html (W3C Members only)]

Options:

1. Add the ID attribute, with a magic application of the ID datatype.

2. Add the ID attribute, using existing mechanisms (DTD) to apply the ID datatype.

3. Authors are free to add their own attributes (issue 30) and so we don't need to do anything. (Editors recommendation)

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0495.html - W3C Members only):

Much discussion, straw poll leaning towards adding it; chair called for objections to adding it; Connolly, Maler object; it will be added to the next draft (ACTION to the editors to do so).

Ben Trafford: The example used to switch between the processors is fine as programming code, but how could someone specifically make a request within the document to activate the inclusion mechanism? I'm envisioning people using an XInclude-aware processor, that only processes the inclusions when requested to (via a stylesheet mechanism seems the most obvious way to me).

Options:

1. Whether to process includes or not is a property of a document instance and syntax to control this should be developed.

2. Whether to process includes or not is a property of a processor, and no document-level syntax should be developed. (Editors recommendation)

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0376.html - W3C Members only):

This is an API issue. Drop this issue--that is, adopt option 2.

Are there any requirements in particular that the Schema WG has of XInclude? For instance, Schema has a facility for mapping included documents to the including document's namespace instead. We could provide this feature as well.

Options:

1. Add a preserve-namespace attribute that specifies namespace results.

2. Formally ask Schema what requirements they have, perhaps setting up a Core/Schema liason.

3. Both 1 and 2.

4. Close this issue in absence of specific input from the Schema WG.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000AprJun/0402.html - W3C Members only):

Option 4: close the issue.

Should we support the inclusion of characters within a CDATA section?

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0252.html - W3C Members only):

If this is about whether we need to worry about the fact that we can't do an xinclude from within a cdata section, we decided we didn't need to worry about this--issue closed, nothing to do.

If this is about having an xinclude pointing into the middle of a cdata section, we decided this was just issue 13, so it's resolved, and issue 26 is closed.

Should an XInclude processor expose attribute(s) indicating whether a node was included or not? If so, should any relevent inclusion information be present, such as include href, steps and parse.

Options:

1. Provide an attribute or infoset item indicating that inclusion was performed.

2. Provide attributes or infoset item encompassing all of the inclusion details.

3. Do nothing - this information is available in the original infoset which is good enough. (Editors recommendation)

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0376.html - W3C Members only):

Though various people felt something like this would have advantages, we had consensus not to have such an attribute. (Adopt option 3.)

When the href attribute specifies a range, should the range nodes be included in order or should ranges be disallowed.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0252.html - W3C Members only):

Allow all ranges, must do some balancing process as in the DOM.

An advantage of XML 1.0 external entities is that external references may be defined and then re-used. Include could be augmented by the same notion of defining external entities and then consumption by include elements. A locator element could specify a remote resource using an href attribute and named by a name attribute. An include element could use an eref attribute instead of an href. The eref on the include would match the name attribute of the locator element. While it is possible for include to specify the href attribute via an xpointer expression, include does not currently allow a dereference of the resulting attribute. Example: <locator href="xyz" name="abc"/><include eref="abc"/>

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0315.html - W3C Members only):

Show how this can be done without any new syntax.

Should something other than ignoring the document element declaration be performed on document nodes?

Options:

1. No known issue here - close it. (Editors recommendation)

2. Clarify what the issues may be.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0376.html - W3C Members only):

Use infoset terminology (i.e., "does not include the document info item"); igore the document type info item.

The steps attribute is included to allow a parser to protect itself from combinatorial explosion of includes. Should steps be removed because it cannot solve the combinatorial include problem? It was pointed out in the XML Link face to face meeting that steps may be an incorrect mechanism for to solve this problem. This issue is that an author will probably want to specify steps="*" for any and all nodes and inclusion, or the author will want to specify steps="1" to simply include the next set of nodes. It will be very difficult for an author to know the correct level of steps to prevent inclusion exposion. A separate mechanism must be used by an include processor to allow protection from this case.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0315.html - W3C Members only):

Remove the steps attribute.

It would also be possible for it to be a completely different [xlink:type] value, making it clearer that other XLink attributes were not relevant. [Richard Tobin]

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0315.html - W3C Members only):

XInclude and XLink are different things. XInclude merges infosets, XLink relates separate infosets. Keep the separate syntax/namespace.

Should the syntax be expressed instead through a qualified role value? [Paul Prescod in http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/1999Aug/0209.html (W3C Members only)]

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0315.html - W3C Members only):

XInclude and XLink are different things. XInclude merges infosets, XLink relates separate infosets. Keep the separate syntax/namespace.

ID validation is merely a schema validation issue and should not be separated out as its own "point." [Paul Prescod: http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/1999Aug/0211.html (W3C Members only)]

Options:

1. Remove the ID section completely.

2. Describe (informatively) how IDs behave under inclusion.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000AprJun/0402.html - W3C Members only):

Option 1: remove the ID section.

Technically speaking, XInclude inclusion *cannot* occur before DTD validation. DTD validation is done by the XML processor: by definition it is accomplished before an information set is created. If you want DTD-syntax validation that works on information sets the you need to specify it yourself as the HyTime people did. SGML and XML just do not support it natively. [Paul Prescod: http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/1999Aug/0211.html (W3C Members only)]

From Ben Trafford: Couldn't you guys define a normative addition to the internal subset that would allow for XInclude validation, and then state than an XInclude-aware processor makes this addition to the infoset based on the parsing of the internal subset? Basically, a 'virtual internal subset'.

Options:

1. Remove mention of DTD validation (other than perhaps a note that DTD processing occurs during creation of an infoset and thus is past before inclusion processing occurs. (Editors recommendation)

2. Define a variant of DTD validation that works on infosets so that inclusion can occur before DTD validation.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000AprJun/0314.html - W3C Members only):

Option 1.

I do not believe that XInclude should hard-code its relationship to schema validation. If I want to write an application that does inclusion and then validates the resulting document, I should be allowed to. [Paul Prescod: http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/1999Aug/0211.html (W3C Members only)]

Options:

1. Remove the hard-coded relationship to schema validation. The relationship of validation and an infoset is outside the scope of XInclude. (Editors recommendation)

2. Do nothing - current relationship is adequate.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000AprJun/0314.html - W3C Members only):

Option 1.

Should exposure of base URI information be required? It appears necessary for applications that wish to operate on URIs in the result.

Options:

1. xml:base provides for this information to be surfaced in a generic way. No more is necessary. (Editors recommendation)

2. Mandate that base URI information is surfaced in some way by applications of XInclude infosets.

Resolution (see - W3C Members only):

Obsolete issue - irrelevant considering XML Base and Infoset changes.

Should we support inclusion of arbitrary ranges? What about simple text substrings?

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0252.html - W3C Members only):

Since substring is just one kind of range (see issue 24), we will support substrings.

Should attempted inclusion of attributes be ignored instead of generating an error?

Options:

1. Yes, they should be ignored.

2. No - current error behavior is best. (Editors recommendation)

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JulSep/0010.html - W3C Members only):

Option 2 - no change. Make the wording a bit more generic to cover namespace nodes as well.

XSLT transformations can operate on document fragments. Should we expand our scope to include fragments as well?

Options:

1. No such thing as an infoset fragment, is there? Close this issue without doing anything. (Editors recommendation)

2. Indicate that inclusion can be applied to an entire infoset, or a portion of an infoset, including arbitrary fragments.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0376.html - W3C Members only):

Drop issue with no action--that is, adopt option 1.

Are there any tricky whitespace issues to consider?

Options:

1. No known issue here - close it. (Editors recommendation)

2. Clarify what the issues may be.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0376.html - W3C Members only):

As long as we don't say anything about whitespace, there seems to be no issues at the Infoset level.

Should we have a simpler mechanism for including the children of the identified node? This would be especially useful for simulating text entities:

<entity-declaration id="nbsp">&#160;</entity-declaration>
    <include xinclude:href="#xpointer(id('nbsp')/text())"/>

Could be instead specified by something like:

<xinclude:include href="#nbsp" children-only="yes"/>

or

<xinclude:include-children href="#nbsp"/>

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0252.html - W3C Members only):

No simpler mechanism needed.

Do we need to specify anything about merging documents with different character sets? For instance, what about merging a Japanese doc with an US-ASCII doc? Or does the Infoset already imply normalization into Unicode?

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0252.html - W3C Members only):

No action needed, consider editorial improvements.

Do you want to outlaw (section 3.3.1) apparent recursion that is in fact prevented by the steps attribute? It would be nice to be able to use circular links to build circular data structures. [Richard Tobin]

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0315.html - W3C Members only):

Remove the steps attribute.

Should we investigate a shorthand for inclusion? The syntax for entity references is minimal (although the overhead of a DTD is not), and may provide a model.

David Orchard: External entites allow the definition and then use of a resource, currenty defined in XML 1.0 DTDs. A proposal to combine XInclude and entities could involve the creation of a Locator element that specifies a name and an href. Similar to the include-indirection-using-locators issue, xi:include could add the attribute of eref (entityname) that specifies the name of a Locator element. This would be used instead of href when eref was present. Then parse and steps are used as normal. &name; means steps="1" and parse="xml", ie &name; is short for <xi:include steps="1" parse="xml" ename="name">. This involves changing the xml 1.0 specification for name references.

Paul Prescod notes [http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/1999Aug/0211.html (W3C Members only)]: "You guys are in the same jam as the XML Schema people. You have to decide what level you want to work at and live with it. If you are working on infosets then &foo; syntax is long past resolved (or reported as an error) unless you are going to go in and hack the XML 1.0 specification."

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0315.html - W3C Members only):

No shortcut syntax needed.

Do we leave remaining xi:includes alone at that point or do we signal an error if any remain? In other words, is this an assertion of the max depth, or the definition of the max depth?

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0315.html - W3C Members only):

Remove the steps attribute.

The proposal implies that the destination documents are knitted before inclusion, which we agree is the right behaviour, but we need some way to optimise this (including an element which doesn't have any links in it, but is in a document which does, should not require following all the links in that document). [Richard Tobin]

Options:

1. Indicate that such optimization is allowed. (Editors recommendation)

2. Indicate that such optimization must be performed - otherwise there may be subtle interoperability problems - for instance, including a subresource in a document that contains an illegal include. A processor with no optimization will report an error, an optimized one won't.

3. Do nothing - draft is clear enough.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000AprJun/0474.html - W3C Members only):

Split into issues XInclude-50-processing-model and XInclude-51-nesting-switch.

A reserialised document will lose the base URL information; do we need an [xi:base-url] attribute that can be added to any element? [Richard Tobin]

Options:

1. This is a serialization issue that can be handled with xml:base. Wait and see how xml:base is integrated into the Infoset before revisiting this one.

Resolution (see http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JulSep/0010.html - W3C Members only):

Serialization is out of scope, close the issue with no change.