- From: Chris Lilley <chris@w3.org>
- Date: Tue, 19 Mar 2002 16:36:26 +0100
- To: Brian McBride <bwm@hplb.hpl.hp.com>
- CC: Paul Grosso <pgrosso@arbortext.com>, "Jonathan Borden" <jonathan@openhealth.org>, <www-tag@w3.org>
On Tuesday, 19 March, 2002, 09:38:25, Brian wrote: BM> At 14:20 18/03/2002 -0600, Paul Grosso wrote: BM> [...] >>No! People keep getting this wrong, and unfortunately major browsers >>do too which is really making a mess of the use of base URLs to the >>point where one cannot use <base> and <a href="#xxx"> sorts of references >>together, because this misinterpretation of #xxx refs with respect to >>base URL destroys the ability to maintain intradocument xrefs. BM> That looks like an eminently reasonable requirement for HTML. That seems like marginalization to me - the HTML WG is clearly working to make XHTML be generic XML, and the same methods should apply to XHTML, SVG, MathML, SMIL, fooML and barML when there is xml:base and a link with a URI that is just a fragment identifier. The same interpretation should apply in all cases that use xml:base and that interpretation should be in the xml:base spec, not in any spec that is a client of xml:base. BM> Let me explain what RDF is trying to accomplish. BM> For good or ill, RDFCore has inherited a situation where: BM> <rdf:Resource rdf:ID="foo"> BM> names a resource whose URI is <base-uri>#foo, i.e. it is relative to the BM> document containing the element. (Request for clarification - the rdf:ID attribute is of type ID in the DTD or Schema?) BM> These relative references cause problems. One of the most frequent newbie BM> errors with DAML+OIL I have seen is "I have tried processing BM> http://www.daml.org/example.daml[*], and it didn't work right." The reason BM> is that the user should be using BM> http://www.daml.org/example. http://www.daml.org/example.daml contains BM> exactly the same text, but because it contains these pesky relative BM> references using rdf:ID, the URI's generated by the parser are wrong. BM> I first came across this problem when I copied the RDF schema to my hard BM> drive so I could work on some code on a plane. I was a little surprised to BM> find I had uri's of the form: BM> file:c:\temp\rdfschema.rdf#Class 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. BM> What is needed is a way to specify, in the XML document, a base for BM> converting relative URI references to absolute form. Then it would not BM> matter, where the file was accessed from. BM> The other obvious use case is where the RDF in question has no obvious URI, BM> e.g. when it is generated as part of protocol, perhaps for e.g. in cc/pp. BM> Whilst the RDF community could invent its own mechanism for this, further BM> divergence of RDF from XML does not seem like a good thing. We have BM> decided therefore, to test whether we can use xml:base for this purpose. That does seem to be the purpose of xml:base. However the MIME registration for RDF gets to define fragment identifiers in whatever way is appropriate. BM> It seems that HTML and RDF have different goals here. I wonder if there is BM> a way to reconcile them. Lets not restrict this to "HTML vs RDF" but try to see a wider picture. BM> ps: It would to keep clearly separate in our minds, the issue of what does BM> a URI (reference) identify and the use of xml base. I don't see how it is possible to separate them. The meaning of the latter is intimately dependent on the former. -- Chris mailto:chris@w3.org
Received on Tuesday, 19 March 2002 10:39:20 UTC