[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [xml-dev] Re: determining ID-ness in XML
- From: Michael Brennan <Michael_Brennan@Allegis.com>
- To: xml-dev@lists.xml.org
- Date: Mon, 05 Nov 2001 15:59:46 -0800
Is there any reason why XLink labels cannot be used for this? If you want to
use a simple name in a fragment identifier, why not treat the referenced
element as a resource and give it an xlink:label attribute, and modify
XPointer to permit use of XLink label names as fragment identifiers as an
alternative to IDs?
> -----Original Message-----
> From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu]
> Sent: Monday, November 05, 2001 1:51 PM
> To: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] Re: determining ID-ness in XML
>
>
> At 4:24 PM -0600 11/5/01, Bullard, Claude L (Len) wrote:
> >Isn't the point to use a means the XML processor
> >isn't free to ignore per specification? That is
> >why the concept of "reliability" was introduced
> >although one could say "efficiency" and mention
> >the cases of XPointers and serialization.
> >
>
> No. That's not the point. It never has been. The XML processor is
> most certainly free to ignore the semantics of xml:id, just like
> today it ignores the semantics of xml:base. In fact, I would be very
> surprised if an XML processor did recognize anything special about an
> xml:id attribute. The client application that receives data from the
> XML processor would impart certain semantics to xml:id, though even
> there it would be free to ignore the standard semantics and apply
> local processing rules instead, or simply ignore the attribute
> completely, if that's what made sense to the people using the client
> application. Of course this is exactly how every other specification
> is implemented in practice today. Local client apps can always do
> whatever they need to do.
>
> 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. This could be done purely within the XPointer specification
> without touching XML core. This reminds me a little of the type
> debate a month ago, so let's steal a march from that flame war and
> change the vocabulary so we stop getting confused.
>
> I officially withdraw my request for a standard xml:id attribute for
> XML documents.
>
> I issue a new request for a standard xml:target attribute. This would
> provide a unique name for XPointers to link to. It would have no
> necessary type. It would have no affect on validity. The documents in
> which it appears may or may not have DTDs, may or may not be valid,
> and may or may not declare this attribute with any particular type.
> Whether such a document was valid would be determined exactly
> according to the rules of XML 1.0. If xml:target (and everything else
> in the document) were properly declared the document would be valid.
> If xml:target were not properly declared, the document would not be
> valid. No parsers would change. The definition of validity would not
> change. The only necessary change would be to XPointer and other
> client specifications that needed to pay attention to this attribute.
> Everybody else can ignore it.
>
> 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; 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.
>
> >One extends the system vocabulary precisely because
> >it extends the requirement for the XML processor.
> >If all you need is a convention, a PI or an
> >alternative namespace are equally ignorable.
> >Otherwise, we could just go on as is: "if you
> >need an ID, spec a DTD and cite it in the
> >contract for the communication when using
> >well-formed files. This is only as reliable
> >as your partners are diligent."
> >
>
> I'm not quite sure where you draw the line on what is and is not the
> system vocabulary. I could implement the xptri scheme in my own
> software today without stepping on anyone's toes. That's what the X
> in XML is all about. But it would probably be easier if we all agreed
> on using the same thing for the same job.
>