Re: 3023 update (was Re: Agenda TAG Telcon: 8th Nov 2004)

Chris Lilley wrote:

>On Monday, November 22, 2004, 1:23:05 PM, David wrote:
>
>DC> That said, what the browsers actually do with #foo in the case of
>DC> arbitrary XML served as application/xml styled with XSL via the
>DC> xml-stylesheet pi is interpret the fragid in the (x)html that is
>DC> generated internally by the stylseet, not as an identifier in the XML
>DC> that is actually served. So even here (if one wanted to standardise
>DC> currently implemented behaviour) a pure XML xpointer based fragid syntax
>DC> wouldn't really help...
>
>That is a very good point, which I  isolated to comment on so it doesn't
>get lost. Its one instance of a processing pipeline; the content as
>served has one media type, but then processing (xslt, xinclude,
>whatever) happens to it so that the displayed resource is of another
>media type.
>  
>
It is clear that media types do not magically solve all problems. There 
are well known issues relating to URIrefs and content negotiation i.e. 
although the fragid stays the same, the structure of the document and 
rules for locating the frag within the document depend on the media type.

That is why it would be nice to have a generalized fragment identifier 
syntax. Hmm... let's see,  we suggested this awhile ago:

http://www.openhealth.org/RDDL/fragment-syntax
http://quimby.gnus.org/internet-drafts/draft-borden-frag-00.txt

but lobbing an internet draft without attending gazillions of IETF 
meetings doesn't get much accomplished :-)

That said, at least XPointer can be a generic syntax for the subset of 
media types that are XML.

>There are known problems where the type of the derived resource is
>assumed by the client (eg in WinIE, where anything created by XSLT is
>assumed to be text/html) but equally, its not clear how to declare the
>type of the derived resource. Not how to address it - link into it, etc.
>Is it a resource, since it does not have a URI? Is it perhaps a
>secondary resource?
>  
>
That was what I was calling a "sub resource" above (but perhaps 
subresource is an already overloaded term itself). The additional issue 
of preserving "secondary resources" across XSLT is a whole 'nuther 
kettle of fish. Basically you'd need some sort of map to link nodes in 
the source document with nodes in the result document...

>This has knock-on effects on various TAG findings.
>  
>
I don't think there is much of any official w3c work on preserving IDs 
across transforms, so short of some new research I can't see how you are 
going to be able to solve that issue.

Perhaps now that we have xml:id, the simplest stance would be to declare 
victory and let XML fragids be whatever is declared as a DTD ID or 
xml:id (unless XPointer is specifically indicated to be the fragid 
syntax for a specific media type registration.)

Jonathan

Received on Monday, 22 November 2004 16:29:38 UTC