[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [xml-dev] 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
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.
From: Tim Bray [mailto:firstname.lastname@example.org]
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