Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Re: determining ID-ness in XML
 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@n...] > 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... 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
