RE: [xml-dev] Re: determining ID-ness in XML

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Good.  From a doctrinal perspective, that is 
exactly what one would want to see and for the 
fragment ID, it works reliably with the PDF 
document.  It doesn't for XML.

The XSLT issue just came up in conversation here. 
Good catch.  However, doesn't this add a requirement to the 
problem:  IDs must be invariant under transformation. 
At that point, I'm unsure where the requirement has 
to be satisfied given that the identity of the document 
going in is not the same as the one coming out. 
It seems to be that XPointers, being based on an 
apriori, can always fail if the target has been 
transformed and the language users has to be 
aware of that.  None of the solutions actually 
can do much to prevent the document edit problem 
if the in-memory representation is changing, yes or no?

Even if we are circling the problem, we are 
defining it in terms that can be compared across 
a web architecture doctrine that includes many 
notations.  This helps because when an application 
designer (eg, the SOAP) designer deprecates standard 
means that support doctrinal requirements, it is 
incumbent on them to specify and prove the alternative or 
their drafts should be rejected.

len

From: David Carlisle [mailto:davidc@nag.co.uk]

>   Again, what 
> does an XPointer do with a PDF document? 

Nothing,  but a URL ending in a fragment id _does_ do something, or can
at least, for a PDF document as PDF files have a consistently defined
(for pdf) internal id notion, so if you have internal named labels in
the pdf then 
http:......xxx.pdf#foo
can work as desired and xxx.pdf can load into your pdf browser, scrolled
to show the location marked with the label foo.

Within the specifc domain of XML documents, saying "Xpointer" and "URI
fragment identifier" is supposed to be the same thing, but for pdf they
are quite different. Surely the trouble that we're trying to address is that

http:......xxx.xml#foo
doesn't reliably work, and PDF doesn't have that problem, does it?

Of course even if we get something specified for XML the problem doesn't
go away, it just shifts around a bit, in particular many XML files will
have a xml-stylesheet PI specifying a transform, and then you have to
decide whether the #foo means an ID from the XML document or in the
generated HTML (or PDF or whatever else is generated). If it means the
latter, much of the current discussion is moot. (If the transform is
happening on the client then I think that the #foo is supposed to be
the fragment identifier of the mime type received (ie XML so Xpointer)
although in practice IE at least treats it as a name in the generated
HTML, which can be useful sometimes...