]>
XML Inclusions (XInclude) Version 1.0 xinclude-&year;&MMDD; W3C Working Draft &day;&month;&year; &XInclude; HTML XML http://www.w3.org/TR/xinclude http://www.w3.org/TR/2000/WD-xinclude-20000717 Jonathan Marsh Microsoft jmarsh@microsoft.com David Orchard Jamcracker dorchard@jamcracker.com

The XML Core Working Group, with this &year; &month; &day; XInclude working draft, invites comment on this specification.

The W3C Membership and other interested parties are invited to review the specification, provide comment, and report early implementation experience. The area of work covered by this specification was outlined in the XML Inclusion Proposal (XInclude), W3C Note of 23 November 1999 . The purpose of publishing this draft is to update the community on our progress in this area and to solicit feedback on the current draft. It should be noted that the WG plans to take this specification to a Last Call review in the near future.

While the WG has decided to publish this working draft, outstanding issues remain as noted in the draft. Based on feedback from the user community, this draft has returned to the element-based syntax of the March 22nd working draft.

Comments on this document should be sent to www-xml-xinclude-comments@w3.org, which is publicly archived. While we welcome implementation experience reports, the XML Core Working Group will not allow early implementation to constrain its ability to make changes to this specification prior to final release.

It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C working drafts can be found at http://www.w3.org/TR/.

This document specifies a processing model and syntax for general purpose inclusion. Inclusion is accomplished by merging a number of XML Infosets into a single composite Infoset. Specification of the XML documents (infosets) to be merged and control over the merging process is expressed in XML-friendly syntax (elements, attributes, URI References).

 English February 28, 2000: First Working Draft. July 5, 2000: Second Working Draft.
Introduction

Many programming languages provide an inclusion mechanism to facilitate modularity. Markup languages also often have need of such a mechanism. This proposal introduces a generic mechanism for merging XML documents (as represented by their information sets) for use by applications that need such a facility. The syntax leverages existing XML constructs - elements, attributes, and URI references.

The requirements used to guide the development of XInclude may be found in the XML Inclusion Proposal W3C Note of 23 November 1999 .

Relationship to XLink

XInclude differs from the linking features described in the XML Linking Language , specifically links with the attribute value show="embed". Such links provide a media-type independent syntax for indicating that a resource is to be embedded graphically within the display of the document. XLink does not specify a specific processing model, but simply facilitates the detection of links and recognition of associated metadata by a higher level application.

XInclude, on the other hand, specifies a media-type specific (XML into XML) transformation. It defines a specific processing model for merging information sets. XInclude processing occurs at a low level, often by a generic XInclude processor which makes the resulting information set available to higher level applications.

Simple node inclusion as described in this specification differs from transclusion, which preserves contextual information such as style.

 Relationship to XML External Entities

There are a number of differences between XInclude and XML external entities which make them complementary technologies.

Processing of external entities (as with the rest of DTDs) occurs at parse time. XInclude operates on information sets and thus is orthogonal to parsing.

Declaration of external entities requires a DTD or internal subset. This places a set of dependencies on inclusion, for instance, the syntax for the DOCTYPE declaration requires that the document element be named - clearly orthogonal to inclusion in many cases. Validating parsers must have a complete content model defined. XInclude is orthogonal to validation and the name of the document element.

External entities provide a level of indirection - the external entity must be declared and named, and separately invoked. XInclude uses direct references. Applications which generate XML output incrementally can benefit from not having to pre-declare inclusions.

The syntax for an internal subset is cumbersome to many authors of simple well-formed XML documents. XInclude syntax is based on familiar XML constructs.

 Relationship to DTDs

XInclude defines no relationship to DTD validation. XInclude describes an infoset-to-infoset transformation and not a change in XML 1.0 parsing behavior. XInclude does not define a mechanism for DTD validation of the resulting infoset.

 Relationship to XML Schemas

XInclude defines no relationship to the augmented infosets produced by applying an XML Schema. Such an augmented infoset can be supplied as the input infoset, or such augmentation may be applied to the infoset resulting from the inclusion.

 Relationship to Grammar-Specific Inclusions

Special-purpose inclusion mechanisms have been introduced into specific XML grammars. XInclude provides a generic mechanism for recognizing and processing inclusions, and as such can offer a simpler overall authoring experience, greater performance, and less code redundancy.

 Terminology

The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this specification are to be interpreted as described in .

 Processing Model

Inclusion as defined in this document is a specific type of XML Information Set transformation.

The input for the inclusion transformation consists of a source infoset. The output, called the result infoset, is a new infoset which merges the source infoset with the infosets of resources identified by URI references appearing in include elements. Thus a mechanism to resolve URIs and return the identified resources as infosets is assumed. Well-formed XML entities that do not have defined infosets (e.g. an external entity file with multiple top-level elements) are outside the scope of this specification, either for use as a source infoset or the result infoset.

Inclusion is indicated by the presence of include elements in the source infoset. An include element is any element matching the syntactic requirements set forth in this specification. The information items located by the include element's URI reference are called the included items. The result infoset is essentially a copy of the source infoset, with each include element, replaced by its corresponding included items.

The Include Location

The value of the href attribute is interpreted as a URI reference. The set of characters allowed in an href attribute is the same as for XML, namely . However, some Unicode characters are disallowed from URI references, and thus processors must encode and escape these characters to obtain a valid URI reference from the attribute value.

The disallowed characters include all non-ASCII characters, plus the excluded characters listed in Section 2.4 of , except for the number sign (#) and percent sign (%) characters and the square bracket characters re-allowed in . Disallowed characters must be escaped as follows:

Each disallowed character is converted to UTF-8 as one or more bytes.

Any octets corresponding to a disallowed character are escaped with the URI escaping mechanism (that is, converted to %HH, where HH is the hexadecimal notation of the byte value).

The original character is replaced by the resulting character sequence.

The base URI for relative URIs is the base URI of the include element as specified in XML Base . The URI resulting from resolution to absolute URI form is called the include location.

 Included Items when parse="xml"

When parse="xml", the include location is dereferenced and the resource is fetched. This resource is treated as an XML resource, and is parsed into an information set. Include elements in this infoset are recursively processed to create the acquired infoset.

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?

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, or a syntax error in an XPointer) result in an error. Resources that contain non-well-formed XML result in an error.

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

The fragment part of the URI reference is interpreted as an XPointer when parse="xml". The XPointer indicates that a subresource, or part of the acquired resource, is the target for inclusion.

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

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

The set of included items is derived from the acquired infoset as follows:

Document Information Items

An include location might identify the document node (for instance, a URI reference without an XPointer, or an XPointer specifically locating the document root. In this case, the set of included items is the children of the acquired infoset's document information item, except for the document type declaration information item child, if one exists.

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.

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.

 Add example of ignorable and non-ignorable whitespace.

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

 Multiple Nodes

An include location with an XPointer might identify a subresource that consists of more than a single node. In this case the set of included items is the set of information items from the acquired infoset corresponding to the nodes referred to by the XPointer, in the order in which they appear in the acquired infoset.

If the document element in the source infoset is an include element, it is an error to attempt to replace it with more than a single element.

 Range Locations

An include location with an XPointer might identify a location set that represents a range or a set of ranges.

Each range corresponds to a set of information items in the acquired infoset. An information item is said to be selected by a range if it occurs after (in document order) the starting point of the range and before the ending point of the range. An information item is said to be partially selected by a range if it contains only the starting point of the range, or only the ending point of the range. By definition, a character information item cannot be partially selected.

An information item is potentially included if it is either selected selected or partially selected by the range. The children property of selected information items is not modified. The children property of partially selected information items is the set of information items that are in turn either selected or partially selected, and so on.

The set of included items is the union, in document order with duplicates removed, of the potentially included information items corresponding to each range.

 Element, Cmment, and Processing Instruction Information Items

An include location that contains an XPointer might identify an element node, a comment node, or a processing instruction node, respectively representing an element information item, a comment information item, or a processing instruction information item. In this case the set of included items consists of the information item corresponding to the element, comment, or processing instrution node in the acquiring infoset.

 Attribute and Namespace Declaration Information Items

An include location that contains an XPointer might identify an attribute node or a namespace node. Identifying such a node is an error.

 Encodings

Note that the character encodings of the including and included resources can be different. This does not affect the resulting infoset, but may need to be taken into account during any subsequent serialization.

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]

 Inclusion Loops

When recursively processing an include element, it is an error to process an include element with an include location that has already been processed in the inclusion chain.

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

In other words, the following are all legal:

An include element with a parse="text" attribute may reference the document containing the include element.

An include element may identify a different part of the same local resource.

Two non-nested include elements may identify a resource which itself contains an include element.

The following are illegal:

An include element with a parse="xml" (or no specified parse value) pointing to itself or any ancestor thereof.

An include element pointing to any include element or ancestor thereof which has already been processed at a higher level.

 Included Items when parse="text"

When parse="text", the include location is dereferenced and the resource is fetched. This resource is treated as a plain text resource.

A range of characters (the selected range) may be identified by a fragment identifier. The syntax of the fragment identifier is interpreted using the syntax of the fragment identifier for the media type text/plain. In the absence of a fragment identifier, the selected range contains all the characters in the document.

There is currently no standard defining fragment identifiers for the media type text/plain. So it is currently an error to specify a fragment identifier when parse="text".

The set of characters in the selected range is converted to a set of included items as follows:

An entity start marker information item. The entity property is set to an entity declaration information item with the following property values:

entity type is "external general entity".

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

name is null.

system identifier is the include location for the include.

public identifier is null.

base URI is the include location for the include.

notation is null.

content is null.

charset The name of the character encoding in which the entity is expressed.

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"?

For each character in the selected range, a character information item is created. The character code is set to the character code representing the character in ISO 10646 encoding. The element content whitespace flag is set to false.

An entity end marker information item. The entity property is set to the entity property of the corresponding entity start marker.

Resources that resolve to something other than text when parse="text" result in an error.

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

 Creating the Result Infoset

The result infoset is a copy of the source infoset, with each include element replaced as follows:

The information item for the include element is found. The parent property of this item refers to an information item called the include parent. The children property of the include parent is modified by removing the include element information item from it. In place of the include element, the following information items are inserted in order:

An Include Start Marker information item. The parent property of this item is set to the include parent. The include element property is set to the information item representing the include element.

The included items. The parent property of each included item is set to the include parent.

An Include End Marker information item. The parent property of this item is set to the include parent. The include element property is set to the information item representing the include element.

Iintra-document references within include elements must be resolved against the source infoset. The effect of this is that the order in which include elements are processed does not affect the result.

In the following example, the second include always points to the first <&includens;:include> element and not to itself, regardless of the order in which the includes are processed.

<x xmlns:xinclude="&includensuri;"> <&includens;:include href="something.xml"/> <&includens;:include href="#xpointer(x/&includens;:include[1])" parse="text"/> </x>

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

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

Leave unspecified.

Specify that entities are copied from infoset to infoset.

Specify that entities are not copied from infoset to infoset.

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

 Properties Preserved by the Infoset

As an infoset transformation, XInclude operates on the logical structure of XML documents, not on their text serialization. All properties of an information item other than those specifically modified by this proposal are preserved during inclusion.

Namespace Declarations

A source infoset might contain namespace declaration information items. The namespace URI property is considered to be part of the element information item, and merging infosets preserves the namespace of the item. This can result in a different result than a simple cut and paste of XML text source. A serialized result infoset might contain additional namespace declarations when including a sub-resource.

For example, the following document:

]]>

including a node from common.xml:

]]>

results in a document that could be serialized as:

]]>

This differs from a text-level copy and paste in that it retains the integrity of the items from the uri2 namespace. A straight copy and paste could result in either the remapping of element names to an unintended namespace, or a document that is not well-formed with respect to namespaces.

Serialization, and specifically where additional namespace declarations might appear, is not constrained by this specification.

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?

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?

 Base URI

The base URI property of the acquired infoset is not changed as a result of merging the infoset, and remains unchanged after merging. Thus relative URI references in the included infoset resolve to the same URI despite being included into a document with a potentially different base URI in effect. A serialized result infoset may need to add xml:base attributes to indicate this fact.

 Infoset Extensions Include Start Marker

An include start marker information item marks the start of a set of information items resulting from an inclusion.

An include start marker information item has the following properties:

The element information item representing the include element causing the inclusion.

The element information item which contains this information item in its children property.

 Include End Marker

An include end marker information item marks the end of a set of information items resulting from an inclusion.

An include end marker information item has the same properties as an include start marker. The values of these properties is the same as those of the corresonding include start marker.

 Syntax

XInclude defines a namespace associated with the URI &includensuri;. For convenience the prefix "&includens;" is used within this specification to indicate this namespace URI.

The XInclude namespace contains a single element, &includens;:include, which serves as the include element. This element has the following attributes:

A URI Reference indicating the location of the resource to include. This attribute is required.

An enumeration specifying whether or not to include the resource as parsed XML or as text. A value of "xml" indicates that the resource must be parsed as XML and the infosets merged. A value of "text" indicates that the resource must be included as the contents of a text node. This attribute is optional.

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 "parse" are errors.'

The ID of this element. This attribute is provided for convenience in addressing the include element. For the id attribute to be recognized as of type ID, it must be so declared, for example, in a DTD. This attribute is optional.

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

Attributes from other namespaces may be placed on the &includens;:include element. Unqualified attribute names are reserved for future versions of this specification.

The content of the &includens;:include element is not defined by this specification.

The following DTD fragment illustrates a sample declaration for the &includens;:include element:

<!ELEMENT include EMPTY> <!ATTLIST &includens;:include xmlns:&includens; "&includensuri;" #FIXED href CDATA #REQUIRED parse (xml|text) "xml" id ID #IMPLIED >

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.

keep a separate namespace

use the xml namespace. (Editors recommendation)

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

 Conformance Markup Conformance

An element information item is XInclude-conformant if it meets the syntactic requirements for include elements defined in this specification. This specification imposes no particular constraints on DTDs; conformance applies only to elements and attributes.

 Application Conformance

An application conforms to XInclude if it:

supports XML 1.0, XML Namespaces, the XML Information Set, and XML Base

observes the mandatory conditions (must) set forth in this specification, and for any optional conditions (should and may) it chooses to observe, observes them in the way prescribed

performs markup conformance testing according to all the conformance constraints appearing in this specification.

 References RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. Internet Engineering Task Force, 1997. RFC 2279: UTF-8, a transformation format of ISO 10646. Internet Engineering Task Force, 1998. RFC 2396: Uniform Resource Identifiers. Internet Engineering Task Force, 1995. RFC 2732: Format for Literal IPv6 Addresses in URL's. Internet Engineering Task Force, 1999. The Unicode Consortium. The Unicode Standard. Tim Bray, Jean Paoli, and C.M. Sperberg-McQueen, editors. Extensible Markup Language (XML) 1.0. World Wide Web Consortium, 1998. Jonathan Marsh, editor. XML Base. World Wide Web Consortium, 1999. John Cowan and David Megginson, editors. XML Information Set. World Wide Web Consortium, 1999. Tim Bray, Dave Hollander, and Andrew Layman, editors. Namespaces in XML. Textuality, Hewlett-Packard, and Microsoft. World Wide Web Consortium, 1999. Steve DeRose, Ron Daniel, Eve Maler, editors. XML Pointer Language (XPointer). World Wide Web Consortium, 1999. References Jonathan Marsh, David Orchard, editors. XML Inclusion Proposal (XInclude). World Wide Web Consortium, 1999. Steve DeRose, Eve Maler, David Orchard, and Ben Trafford, editors. XML Linking Language (XLink). World Wide Web Consortium, 2000. Examples Basic Inclusion Example

The following XML document contains an include element which points to an external document.

120 Mz is adequate for an average home user.

]]>

disclaimer.xml contains:

The opinions represented herein represent those of the individual and should not be interpreted as official policy endorsed by this organization.

]]>

The infoset resulting from resolving inclusions on this document could be serialized as:

120 Mz is adequate for an average home user.

The opinions represented herein represent those of the individual and should not be interpreted as official policy endorsed by this organization.

 ]]> Range Inclusion Example

The following illustrates the results of including a range specified by an XPointer.

The relevant excerpt is:

]]>

source.xml contains:

Sentence 1. Sentence 2.

Sentence 3. Sentence 4. Sentence 5.

]]>

The infoset resulting from resolving inclusions on this document could be serialized as:

The relevant excerpt is:

Sentence 2.

Sentence 3.

 ]]> Textual Inclusion Example

The following XML document includes a "working example" into a document.

The following is the source of the "data.xml" file:

]]>

data.xml contains:

]]>

The infoset resulting from resolving inclusions on this document could be serialized as:

The following is the source of the "data.xml" file:

<?xml version='1.0'?> <data> <item><![CDATA[Brooks & Sheilds]]></item> </data> ]]> Open Issues List

A tabulation of open issues flagged above follows:

Dummy issue used to record the next unused issue number.

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

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.

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

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]

Indicate that such optimization is allowed. (Editors recommendation)

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.

Do nothing - draft is clear enough.

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

Do we leave remaining &includens;: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?

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, &includens;: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 <&includens;: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."

No shortcut syntax needed.

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]

Remove the steps attribute.

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?

No action needed, consider editorial improvements.

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

  ]]>

Could be instead specified by something like:

]]>

or

]]>

No simpler mechanism needed.

Are there any tricky whitespace issues to consider?

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

Clarify what the issues may be.

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

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

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

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

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

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

Yes, they should be ignored.

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

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

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

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

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

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

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

Obsolete issue - irrelevant considering XML Base and Infoset changes.

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

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

Do nothing - current relationship is adequate.

Option 1.

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

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)

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

Option 1.

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

Remove the ID section completely.

Describe (informatively) how IDs behave under inclusion.

Option 1: remove the ID section.

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

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

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]

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

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.

Remove the steps attribute.

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

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

Clarify what the issues may be.

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

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"/>

Show how this can be done without any new syntax.

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

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

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.

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

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

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

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

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

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.

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.

Add a preserve-namespace attribute that specifies namespace results.

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

Both 1 and 2.

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

Option 4: close the issue.

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

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

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

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

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

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

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

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

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

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

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

Revoke permission to add non-XInclude attributes.

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

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

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?

theUri result: theUri ]]>

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

Develop some other mechanism to provide this functionality.

Don't provide this capability. (status quo)

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.

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.

add an an attribute-based syntax variant

provide only an attribute-based syntax

do nothing

Option 2: move to attribute-based syntax.

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?

yes, mandate a specific splitting algorithm

no, indicate that this is implementation-specific

leave it vague

drop parse="cdata" making this issue obsolete

Option 4: remove parse="cdata".

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.

allow multiple cdata sections to result from the include

preclude multiple cdata sections from resulting from the include

make it implementation-dependent

don't say anything - this is a serialization issue

do nothing - bogus issue

drop parse="cdata" making this issue obsolete

Option 6: remove parse="cdata".

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

We will say that qualified attributes are allowed.

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

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 xmlns "attributes" on xinclude elements? [Subissue of XInclude30 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.

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

add an optional attribute named "id"

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

Duplicate.

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?

yes, add this as a conformance criterion.

no.

Option 1 - Yes.

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?

No. Issue dropped.

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

Closed as subsumed by issue 52.

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.

Accept Jonathan's proposal.

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

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

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.

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

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

ID attribute dropped.

Do requirements belong in this document any longer?

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

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.

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.

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

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

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

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

Provide a switch for turning nested inclusions on and off.

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

Provide no such switch.

Option 3 - nothing.

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.

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.

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.

Return to element syntax.