- From: Jonathan Borden <jonathan@openhealth.org>
- Date: Tue, 19 Mar 2002 12:54:37 -0500
- To: "Chris Lilley" <chris@w3.org>, "Brian McBride" <bwm@hplb.hpl.hp.com>
- Cc: "Paul Grosso" <pgrosso@arbortext.com>, <www-tag@w3.org>
> >
> >(Request for clarification - the rdf:ID attribute is of type ID in the
> >DTD or Schema?)
>
> No. There is no DTD or XML schema for RDF.
> [...]
Think of rdf:ID as if
xml:idatts="rdf:ID"
One _can_ create a RELAXNG grammar for RDF in which case
rdfIDattr = attribute rdf:ID{xsd:ID}
>
>
> >Its clear that any situation where something works online but a
> >local(y accessed) copy suddenly breaks is a problem. The XML MIME type
> >RFC, by introducing a precedence of headers over the XML encoding
> >declaration, has a similar problem.
Right, which is why it would be good practice to qualify such RDF documents
with an xml:base if this works as currently suggested by RDFCore.
>
> I should be clear. It is possible to write RDF/XML such that it does not
> have this problem. Instead of rdf:ID, one can write:
>
> <rdf:Description rdf:about="http://....">
>
> where the contents of the attribute is the full URL. One can also use
> entities to reduce the amount of typing. The problem we have is:
>
> o some folks depricate the use of entities
> o typing out the full URI is pretty tedious and unfriendly
> o the rdf:ID idiom is common and used in other specs such as daml+oil,
> PRISM and cc/pp.
>
> Thus the use of the rdf:ID idiom is preferred.
And likewise the <rdf:Description rdf:about="#foo"> idiom, e.g. see
http://www.daml.org/2001/03/daml+oil
>
> [...]
>
> >Lets not restrict this to "HTML vs RDF" but try to see a wider picture.
Right, one is an example of an application that tends to dereference URIs
and divides processing of the URI part and the fragment id part to
server/client respectively. The other is an example of an application that
tends not to dereference URIs and treats URIreferences as opaque names. From
where I sit, the two applications can coexist, and coexist well, as long as
we allow some flexibility.
Jonathan
Received on Tuesday, 19 March 2002 12:57:28 UTC