RE: [xml-dev] So maybe ID isn't a problem after all.

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

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@textuality.com]

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