Re: Generic processing of Fragment IDs in RFC 3023bis

On Thu, Oct 7, 2010 at 10:38 AM, Graham Klyne <GK-lists@ninebynine.org> 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
(http://www.w3.org/XML/9710rdf-dtd/rdf.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 Thursday, 7 October 2010 22:37:09 UTC