W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

Re: Options for dealing with IDs

From: Dave Beckett <dave.beckett@bristol.ac.uk>
Date: Fri, 10 Jan 2003 17:33:57 +0000
To: Chris Lilley <chris@w3.org>
cc: Brian McBride <bwm@hplb.hpl.hp.com>, Tim Bray <tbray@textuality.com>, www-tag@w3.org
Message-ID: <10890.1042220037@hoth.ilrt.bris.ac.uk>

>>>Chris Lilley said:
> On Thursday, January 9, 2003, 3:04:09 PM, Dave wrote:
> DB> So this remains not an XML ID - there is no normative DTD or XML
> DB> Schema that defines the RDF/XML syntax.
> Notice how the first part derives directly from the second part. There
> is no normative DTD or Schema for RDF/XML so it has no XML IDs, but it
> has attributes called ID whose syntax is identical to XML ID and whose
> use is also the same.


However I'm pretty sure they aren't quite identical since RDF/XML
uses the XML Namespaces restriction on names - NCNAME, over what is
allowed in XML alone - http://www.w3.org/TR/REC-xml#NT-Name

> So, if a means were added so that an RED/XML ...

RDF/XML I assume

> ... instance could add a single attribute to its root
> xml:idAttr="ID"
> and that - without requiring any normative DTD or Schema for RDF/XML -
> meant that the worlds of XML andf RDF were brought into closer harmony
> by making RDF ID and XML ID the same - then that would seem to me to
> be a big win.

It could be added to such an instance so that the ID in the RDF/XML
syntax would be an XML ID (and indeed could be done now, since such
an attribute wouldn't affect how the RDF/XML was parsed into RDF

That would however, mean nothing to the RDF model, since RDF/XML is
just a (recommended) serialization format of RDF and that part of the
XML has no correspondance in the RDF graph.  Of course, in the (a?)
XML model, the Infoset/PSVI the ID attribute remains around and means
things there.

So although you could add such a thing, I expect it would only be
useful if you dealt with the RDF/XML format as XML, not as an
encoding of a different model, RDF's graph.

That might be some significant point since the HTML, SVG etc.
formats that were mentioned in this thread *are* the XML, there isn't
another model they are encoding, and in such cases, the XML ID is
appropriate for fragment identifier.

> >> ... the fragment identifier #foo does *NOT* denote the element with ID 
> >> attribute whose value is "foo".  It denotes the resource described by that
> >> element.
> DB> Yes.
> The behavior of fragment identifiers is up to the MIME registration.
> It is orthogonal to IDness. Making RDF ID be the same as XML ID on a
> per-instance basis would not affect that in the slightest.

RDF uses URIs with fragments (URI References) as opaque identifiers
for resources: http://www.w3.org/TR/webarch/#pr-use-uri

It is a language and has no processing model or behaviour defined.
That means in this case, that given a URI, there is no requirement
for retrival of a representation and content type from it, and no
further interpretation of the result.  (Of course nothing prevents
you doing that in your application we just don't say what happens to
the RDF graph when you do.)

So although xml:idAttr could be added to RDF/XML right now, making an
RDF ID be the same as an XML ID (caveats about which XML ID - XML or
XML NS), it would seem to be primarily of use when dealing with

Received on Friday, 10 January 2003 12:35:09 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:36 UTC