W3C home > Mailing lists > Public > www-xml-xinclude-comments@w3.org > February 2004

RE: Interpretation of fragment IDs when parse="xml"

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Tue, 17 Feb 2004 15:37:01 -0800
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA202A14E1B@RED-MSG-30.redmond.corp.microsoft.com>
To: "Elliotte Harold" <elharo@metalab.unc.edu>, <www-xml-xinclude-comments@w3.org>

These tricky problems disappear with our decision to outlaw fragment
identifiers instead of changing the namespace.

> -----Original Message-----
> From: www-xml-xinclude-comments-request@w3.org
> comments-request@w3.org] On Behalf Of Elliotte Harold
> Sent: Saturday, December 20, 2003 7:11 PM
> To: www-xml-xinclude-comments@w3.org
> Subject: Interpretation of fragment IDs when parse="xml"
> Section 3.1 states:
> For interoperability, fragment identifiers should not
> <http://www.w3.org/TR/xinclude/#dt-must> be used; the interpretation
> application of media-specific fragment identifiers in creating
> info-items is not guaranteed to be supported across implementations.
> I don't thyink this is strong or complete enough, and will lead to
> interoperability problems. I think that if we go with the xpointer
> attribute (instead of using a fragment identifier) then it needs to be
> explicitly stated that XInclude implementations MUST ignore the
> ID in the URI.
> Furthermore, it is unclear what should happen if there is a fragment
> and it is syntacticaly incorrect.
> To be honest, my preferred solution would be to not use the xpointer
> attribute, and simple wait until XML fragment IDs are finished. But if
> we must have the xpointer attribute more thought is required on what
> do with fragment IDs that do appear.
> On a related note, I do not feel it would be acceptable to move
> to PR from this spec. The more I work with it, the more questions I
> have. I think a candidate rec would be a very good idea.
> --
> Elliotte Rusty Harold
Received on Tuesday, 17 February 2004 18:48:08 UTC

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