Re: Generic processing of Fragment IDs in RFC 3023bis


I think the muddle you mention is historically justfied ... the original rdf:ID 
(, section 2.2.1) was just ID, 
and it was intended to be the same as the XML ID as defining a fragment.

This constraint has been carried forward in slightly modified form in the later 
RDF/XML spec:


Jonathan Rees wrote:
> On Thu, Oct 7, 2010 at 10:38 AM, Graham Klyne <> wrote:
>> Jonathan Rees wrote:
>>> (My factual question of whether generic XML processors must treat
>>> rdf:ID the same as xml:id hasn't been answered, by the way - so we're
>>> not sure there's a problem at all!)
>> I would say not.  Despite the apparent similarity of label, rdf:ID and
>> xml:ID are completely different attributes.  (I've seen suggestions that
>> rdf:ID be deprecated, as the same can be achieved using rdf:about.)
> That's great - then there is no problem at all and we can promote
> generic processing without qualification! How did we get so tied up in
> knots about this?
> Well, we would have to make sure that some generic validation doesn't
> reject fragids that are *not* defined by xml:id, i.e. are defined in
> some other way such as rdf:ID. That doesn't seem like much of a
> hardship - add a few words to 3023bis about it being OK if
> *additional* fragids are defined in other ways.
> Here's how I got confused: The RDF/XML DTD
> ( gives the rdf:ID attribute
> type ID, and the XML specs (including xml:id and Xpointer) do their
> very best to ensure that attributes with type ID are as much as
> possible the same as xml:id. The RDF/XML spec also makes rdf:ID very
> similar to xml:id - same syntactic and uniqueness constraints. So it
> seemed highly likely to me that rdf:ID defines fragids the same way
> that xml:id does.
> The flaw in this argument is that this DTD for RDF/XML is not
> normative - nothing in the RDF/XML rec leads to any connection between
> rdf:ID and xml:id. So we should just ignore the DTD, or agitate to get
> it fixed.
> (I still don't know whether having type ID is enough to make an
> attribute fragid-defining.)
> Sorry if I contributed to this muddle.
> Jonathan

Received on Saturday, 9 October 2010 17:09:17 UTC