[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: So maybe ID isn't a problem after all.
Application languages designed too loosely with regards to requirements for use with XPointer. I'm interested, given the standard options, why the designer would do that if their is a requirement that the application language interoperate with XPointer and XLink? HyTime provided some different kinds of addressing forms that did not require the pointer author to know apriori the structure of a document. The use case as I recall was documents to which the pointer author did not have write access, so could not insert link targets. Is it possible that the URI doctrine is inadequate for current requirements? One question before we go on: does the link target have to be an ID or will a formal means to declare a name suffice for XPointer? The xml: namespace is a lot like architectural forms. len -----Original Message----- From: Tim Bray [mailto:tbray@t...] So given a couple weeks to think about this, I'm starting to think that maybe there's no problem. Given an actual real XML language [as opposed to an abstraction] you usually know what the ID attributes are. It's well-defined for SVG, XHTML, and pretty well anything else I can think of. Clearly it's essential that an XLink/XPointer processor have an external interface by which you can tell it "for this resource, XX is an ID attribute". So where's the problem? When you're trying to process an XLink/XPointer into something and the only thing you know about it is that it's XML. Er..... what's the scenario where this happens? -Tim
|
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
|