- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Thu, 25 Oct 2007 12:37:30 -0400
- To: Tim Berners-Lee <timbl@w3.org>
- Cc: "Booth, David (HP Software - Boston)" <dbooth@hp.com>, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "wangxiao@musc.edu" <wangxiao@musc.edu>, W3C-TAG Group WG <www-tag@w3.org>, Alan Ruttenberg <alanruttenberg@gmail.com>, Jonathan A Rees <jar@mumble.net>, Dan Connolly <connolly@w3.org>
On 24 Oct 2007, at 12:01, Tim Berners-Lee wrote: > There are three possible attitudes: > > 1) don't mix HTML and RDF, HTML will always have anchors. I think > that this doesn't meet the need. > > 2) Do mix RDF and HTML, allow one file to define both anchors and > arbitrary things. Don't let the same fragid be used for both an > anchor and a thing. > > 3) Do mix them, and by the way, allow the same fragid to be used as > an ID for an anchor and an ID for a thing, with RDF clients and > HTML clienst doing different things. I think that this path leads > to madness, as in a script for exaple, I may want to use a URI to > refer to one or the other unambiguously. It also makes it > impossible for HTML+RDF clients. > > So (2) is my preference, and I feel it should be written down > somewhere. Actually the MIME type registration for HTML would be > the logical place. A TAG finding could be pragmatic place too. I agree that it's an important issue. I agree that 2) would be a huge improvement over 1), and that 3) is a recipe for disaster. Regarding Xiaoshu's point that 2) doesn't allow us to click on an RDF hash URI and end up scrolled to the right spot in the HTML: I agree that this is a problem. But I think it's a Web browser implementation issue, and can be worked around with in-browser trickery, such as a bit of Javascript. So I'd say there's no need to bend the architecture. Richard > > Tim BL > > >
Received on Thursday, 25 October 2007 16:37:43 UTC