W3C home > Mailing lists > Public > www-xml-xinclude-comments@w3.org > August 2001

RE: HTML WG last call comments on http://www.w3.org/TR/2001/WD-xinclude-20010516

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Wed, 29 Aug 2001 16:00:21 -0700
Message-ID: <330564469BFEC046B84E591EB3D4D59C0336DDBA@red-msg-08.redmond.corp.microsoft.com>
To: "Steven Pemberton" <steven.pemberton@cwi.nl>
Cc: <www-xml-xinclude-comments@w3.org>, <w3c-html-wg@w3.org>
> 2. Terminology
> synonyn => synonym

Fixed.

> A reference to the defining instance of 'information set' would be
useful
> here.

Fixed.

> 3. Syntax
> Refered => referred

Fixed.

> 4.2 Included items when parse="xml"
>     "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."
>
> We couldn't find any definition of what an "error" is, and what
happens to
> processing in error cases.

We have clarified the behavior or errors (the processor must stop), but
define a "resource error" and a recovery mechanism.

> We see a number of use cases for Xinclude in XHTML. One of the major
uses
> today for similar functionality is page counters (using an image). We
hope
> that Xinclude would be able to replace this clumsy technique.
>
> However if the unavailability of the counter resource would mean that
you
> could not view the including page, we, and many millions of others,
would be
> very upset. A good possibility here would be to give the <xi:include>
> element non-empty content. Then if the resource is unavailable, the
> alternative content of the element could be used instead.

We recognize the utility, and have provided an <xi:fallback> element for
the purpose of recovering from resource errors.

> 4.2.5 Attribute and Namespace Declaration Information Items
> There should be a definition, or pointer to a definition, for
"attribute
> node" and "namespace node"

I will make it clearer that each XPointer node corresponds to an
information item, and identifying a node using an XPointer results in
processing of the information item that corresponds to that node.

> 4.3. Included Items when parse="text"
> "if the media type of the file" => "if the media type of the resource"
(you
> might want to check other uses of the word 'file' too).

Fixed.

> Example right above 4.4.1: "xmlns:xinclude" should be "xmlns:xi".

Fixed.

> 4.4.3.2. Base URI
> We can identify use cases for using the base URI of the including
document
> as well as the included document. Especially considering that
server-side
> includes as they exist today use the including document as base, we
would
> like to see the option of specifying which base is used.

Automatic remapping relative URIs is beyond the scope of this
specification.  What use cases do you envision?

> Appendix C.
>
> It would be nice to see an example where a 'real' text file is being
> included.
>
> How about:
>
> <?xml version='1.0'?>
> <document xmlns:xi="http://www.w3.org/1999/XML/xinclude">
>   <p>This document has been accessed
>   <xi:include href="count.txt" parse="text"/> times</p>
> </document>
>
> where count.txt contains (for instance):
>
>     324387

Done.

> Recursive include
> A correspondent points out that despite your rules for recursive
inclusions,
> with judicious use of scripting you could still generate a recursive
> inclusion.

I do not see how the processing model described in XInclude could
provide for injection of script at a point where it could cause
problems.  Even if it did, I would presume such judicious use of
scripting to be evidence that loop detection was handled
programatically.

> A smaller issue is styling. What should the processor do when a style
sheet
> is included? This shouldn't be a problem with an embedded
> <style> element, since anyplace except at the top of the document
would
> create an invalid document. As for linking,
>
> <blockquote cite="http://www.w3.org/TR/xml-stylesheet/">
>    The xml-stylesheet processing instruction is allowed only in
>    the prolog of an XML document. The syntax of XML constrains
>    where processing instructions are allowed in the prolog; the
>    xml-stylesheet processing instruction is allowed anywhere in
>    the prolog that meets these constraints.
> </blockquote>

XInclude does not treat the stylesheet processing instruction specially.
If a document author places a stylesheet processing instruction
somewhere other than the prolog (through XInclude or otherwise), it will
not be recognized.
Received on Wednesday, 29 August 2001 19:51:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:30 UTC