[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [xml-dev] Re: determining ID-ness in XML
- From: Leigh Dodds <ldodds@ingenta.com>
- To: Elliotte Rusty Harold <elharo@metalab.unc.edu>, xml-dev@lists.xml.org
- Date: Tue, 06 Nov 2001 12:32:16 +0000
> -----Original Message-----
> From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu]
> Sent: 05 November 2001 21:51
> To: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] Re: determining ID-ness in XML
>
[...]
> People keep getting confused with what we're really asking for
> because ID has a certain meaning in the context of XML 1.0, but none
> of that's necessary or even relevant here. We are *not* talking about
> XML 1.0 or schema ID attributes. All we're asking for is name we can
> link to.
Are we? The original posting [1] didn't mention linking, just the inability
to identify an ID without a schema. Tim described this a "gaping
architectural hole" [2], and cited linking as the primary use case
demonstrating this hole [3]. Mike also suggested that a mechanism
to identify, erm, identifiers would help tidy up getElementById() [4].
I'm not arguing one way or another here, just trying to set some
bounds to the problem.
If what we're really talking about is an omission from XPointer
(xml:target, or similar) then "gaping architectural hole" seems an
exaggeration. After all it's a fix to one spec, and we've been
round that one before.
The minimal victory may be good enough, but isn't it worth
considering whether there are benefits to be gained from a slightly
more general solution?
> A few people seem to think that the xml: prefix is more special than
> it is. The only thing that's special about it is that the namespace
> doesn't have to be declared;
Not that surprising really. Attributes in the xlink namespace mean something
to xlink processor, similarly for rdf attributes. This thinking naturally
leads one to the conclusion that the 'xml namespace' is of meaning to an
'XML processor', which seems like a more fundamental piece of machinery.
If I understood Len correctly (particularly his allusions to RTF) his
concerns
were that the XML processor might become an increasingly nebulous concept
if all manner of optional xml: extensions are added. If there are some basic
services required then enforce them, if they're optional, then identify
them as separate chunks of functionality.
> ...but if that bothers you we can revise
> this. Instead of using the xml: prefix we can use the xptri prefix
> mapped to the http://www.w3.org/2001/xpointer-instance namespace URI.
> As always the prefix can change as long as the URI remains the same.
I'd say that was preferable, if the scope of this is really just to fix a
hole
in the XPointer spec. It's an attribute of interest only to XPointer
processing.
(Actually one might make an argument here for the use of a PI).
One further point which I'd be interested to see addressed is the following:
if the majority of XML on the web is not going to have a DTD (which seems
implicit in this discussion), is it any more likely that the author will
have
bothered to put a PI, xml:target, xml:id, xml:idatts, etc into the document
either? Don't we need to be able to link to any arbitrary XML document?
Cheers,
L.
[1]. http://lists.xml.org/archives/xml-dev/200110/msg00884.html
[2]. http://www.imc.org/ietf-xml-mime/mail-archive/msg00714.html
[3]. http://lists.xml.org/archives/xml-dev/200110/msg00899.html
[4]. http://lists.xml.org/archives/xml-dev/200110/msg01048.html