Lists Home |
Date Index |
On xml-dev, Daniel Veillard wrote:
> On Fri, Feb 01, 2002 at 02:08:50PM -0500, Jonathan Robie wrote:
> > In HTML, most pointers are done with very simple pointers like this:
> > http://somesite.com/html/top.html#section_2
> Whose semantic is hardcoded in a DTD that nearly no application
> ever respected or used. Let's have a look of the alternatives in XML:
> Hard to rely on it with XML, well last time I suggested on this forum xml:i
> I got a lot of flack back, I won't try again.
> So either you accept to force validation of document (and hence
> possibly have to fetch and trust remote DTD in your framework) or you
> need other pointing schemes.
> [... other pointing schemes ...]
> If you think that
> is simple and fast, yes in a very well defined context, in general it's
> an horrible solution, you have to rely on something outside the document
> itself to simply make that request. //*[@id=foo] at least can work directly
> on the document.
I *strongly* agree with this conclusion.
Something like 'nameloc' is necessary for stable references,
but it doesn't have to be expressed as a barename.
'//*[@id=foo]' (or some other syntax with equivalent semantics)
can accomplish everything that 'id(foo)' can. More, actually:
it also works with documents that don't have (or have but don't
reference) a DTD, W3C XML Schema, or other infoset-augmenting
resource. As an added bonus, the recipient doesn't have to
retrieve (and process!) the DTD/XSD/what-have-you.
On the originating end, if you know that the document has an element
with an ID-bearing attribute with value 'foo' that you want to reference,
then you almost certainly know the name of that attribute,
so requiring '#@attname=value' instead of just '#value' doesn't
Re: the 'xml:id' and 'xml:idattr' proposals: these sound reasonable,
but it seems to me like an awful lot of work to specify, implement,
and deploy just for the sake of barename fragment identifiers.