RE: XInclude Last Call WD 16 May 2001 comments

Thanks for the comments.  Responses below:

> -----Original Message-----
> From: Jonathan Marsh 
> Sent: Wednesday, May 23, 2001 9:37 AM
> To: www-xml-xinclude-comments@w3.org
> Cc: sarowe@textwise.com
> Subject: FW: XInclude Last Call WD 16 May 2001 comments
> 
> 
> 
> 
> Thanks, I'll try to forward it myself...
> 
> -----Original Message-----
> From: Steve Rowe [mailto:sarowe@textwise.com] 
> Sent: Wednesday, May 23, 2001 8:05 AM
> To: Jonathan Marsh
> Subject: FW: XInclude Last Call WD 16 May 2001 comments
> 
> Mr. Marsh,
> 
> I have twice attempted to send the following message to the 
> comments list for XInclude (on 5/18 and on 5/22).  Other 
> messages have appeared since, so the list appears to be 
> selectively (and silently) dropping my messages (and maybe others'?).
> 
> As others have noted, the latest WD is very well written; 
> congratulations to you and your group.
> 
> Steve Rowe
> MNIS-TextWise Labs
> 
> -----Original Message-----
> From: Steve Rowe [mailto:sarowe@textwise.com]
> Sent: Tuesday, May 22, 2001 12:09 PM
> To: www-xml-xinclude-comments@w3.org
> Subject: XInclude Last Call WD 16 May 2001 comments
> 
> 
> Hello,
> 
> Following is a set of small issues concerning the latest 
> XInclude working draft.
> 
> 1. I had to re-read section 4.1 (The Include Location) 
> several times to understand that the encoding/escaping 
> mechanism described applies only to the URI which must be 
> presented to the URI resolver, and not to the literal IURI 
> value of the "href" attribute.  Suggested
> resolution: add section 4.1.1, under which the entire 
> encoding/escaping discussion would be placed, so that the 
> distinction between the two is made more clear.

Accepted.

> 2. In the first sentence of section 4.4.1, "source infoset" 
> should be "result infoset".

Accepted.

> 3. In the third sentence of the first paragraph of section 1, 
> and in the second sentence of the first paragraph of section 
> 4.4.3, "proposal" should be "specification" or "recommendation".

Accepted.

> 4. I previously suggested changes to the C.2 range inclusion 
> example; upon more careful reading of the XPointer WD, I 
> think that it still has problems.  The XPointer WD says that 
> the third and fourth arguments to the "string-range" function 
> default to the character points just before and just after 
> the matched second argument string, respectively.  If 
> specified, they are a start point and a character length, 
> with the 1-based start point being relative to the character 
> point just before the matched second argument string.  As 
> currently written, the example would result in:
> 
>    ...
>    <p><i>Sentence 3.  Sentenc</i></p>
>    ...
> 
> instead of the expected:
> 
>    ...
>    <p><i>Sentence 3.</i></p>
>    ...
> 
> Suggested resolution: either remove the third and fourth 
> argument (so that the end-point would default to just after 
> '3.'), or change the fourth argument (specifying the 
> character length) to 2.  The latter is illustrated below:
> 
>    ...
>    range-to(string-range(chapter/p[2]/i,'3.',1,2)))"/>
>    ...

Accepted.  Thanks for noticing this, it slipped by me during the many
revisions of this section.

> 5. Although it looks like it won't make it into this version 
> of XInclude, it would be useful for XInclude to describe an 
> extension to XML Infoset which would allow for the "infosets" 
> accepted by XPath and XPointer, such as those which would 
> result from parsing an external parsed entity file, which 
> might have multiple top-level elements/character 
> data/comments/PIs.  XInclude's inability to address into XML 
> serializations which are addressable by XPointer seems overly 
> strict, especially since XInclude doesn't constrain the 
> infoset construction method.  My guess is that this is so 
> only because a decision was reached not to extend the Infoset 
> for this version.  Too bad.

Yes, and we re-confirmed this decision.  In order to support this, we'd
need more than just defining how to build an infoset from such resource,
but also we'd have to introduce syntax to differentiate */xml from
*/external-entity, probably of the form parse="external-entity".  We are
trying very hard to keep Xinclude 1.0 as minimal as possible.  We think
this could be reasonably added in a future version.

> Hope it helps,
> 
> Steve Rowe
> MNIS-TextWise Labs
> 
>

Received on Thursday, 28 June 2001 11:18:37 UTC