- From: Mark Birbeck <mark.birbeck@formsPlayer.com>
- Date: Thu, 18 Oct 2007 11:39:43 +0100
- To: "Ben Adida" <ben@adida.net>
- Cc: public-rdf-in-xhtml-tf@w3.org
Hi Ben, > I'm beginning to agree with Manu's argument here. Manu's argument is that since we don't process Dublin Core @rel values, why should we process HTML @rel values? The answer is that we are dealing specifically with 'RDF in XHTML', and the HTML @rel values are therefore part of the spec. Further, we only have an obligation to handle DC values in @rel when there is the correct profile--if there is no such @profile value then from the point of view of HTML, any non-HTML values are just gobbledygook. Now, that doesn't mean that we can't agree to ignore all non-prefixed values, including HTML ones. All I'm saying is that the argument for that would be that we can't find a better solution, and *not* that if we ignore DC values we should also ignore HTML values. However, as I've said below, I think there is a way through this. > I could still be > convinced otherwise, but there is a real value to keeping things simple. There always is. That's probably the most used phrase on any W3C mailing-list. :) > Mark, I think one of the issues is that we cannot expect (nor should we > attempt) to make RDFa the complete solution for parsing all triples in a > page. If we leave the option open for rel="next" to generate a triple, > but we don't specify that an RDFa parser *must* generate one in this > case, then I think we just might be reaching the right balance. Of course. That's one of the many solutions that we could adopt, although it does blow wide open one of the major use-cases surely? That of Creative Commons. Anyway, I have looked at this a bit, and after getting very frustrated with it, I decided to come at it from the other direction; what if we didn't have a legacy problem? What if we were writing this from scratch? How would we make use of the XHTML-vocab values in documents? One possibility would be to define the default prefix mapping to point to the XHTML-vocab, which would allow authors to write: <link rel=":next" href="..." /> <link rel=":prev" href="..." /> This means that we can still make use of the XHTML values--next, prev, license, and so on--but authors wouldn't need to define a URI mapping like "xh:" in order to do so. Before anyone shouts about this, let me explain why I'm suggesting this. Once you have an easy way to make use of the XHTML-vocab values, then you could argue that from an _authoring_ perspective our job is done; we have provided a convenient way to let authors use a list of clearly defined values in their documents. This has the effect of changing the @rel="next" problem into something else--a 'legacy' question. And once it is a legacy question we can apply different criteria to solving that. We could certainly say that at this time we don't know how to deal with legacy values, and for now these values are completely ignored. The good thing is though, that we are not _ignoring_ the XHTML-vocab values; we're merely ignoring one way that those values might be written. > That way, we leave open the possibility of adding hGRDDL to process > Dublin Core profiles, including a default profile for XHTML which > processes non-namespaced items consistently, etc... That's what I said before. :) But in addition, we can now say that just as with @rel="next", DC is a legacy question, rather than a 'new markup' question. To put it a different way, we have a way for DC to be added to documents, and that is the normal RDFa syntax that uses URI mappings. Authors are free to make use of that, so any use of DC.creator with a @profile (for example) is clearly something that goes into our _legacy_ processing bucket. (Note that if it doesn't go into the legacy bucket, then we are essentially saying that we support alternate syntaxes, which goes against the spirit of RDFa.) > In other words, this is a way for us to wrap up the spec *now*, keep > things simple, and keep our options open for the future. I think you are aiming at windmills here. :) I didn't suggest that we add any processing rules *now*. > To Manu's comment: > > If we narrow the scope of this to be only about RDFa in XHTML, that > > would help things greatly. I just wasn't sure that we had narrowed the > > scope to that yet... > > We are *absolutely* talking about RDFa in XHTML1.1. That's our scope, > nothing else :) Yes. > Note one thing that may have slipped through the cracks, but that I need > to bring back up as Creative Commons rep: a while ago, in the previous > WG, we decided to add "license" as a reserved word for @rel. Whatever we > decide to do with this, let's make sure not to forget that one. Yes, "...vocab#license" should definitely be in there--I don't know how it got dropped. So, with your CC hat on Ben, how do you feel about this: This is licensed under a <a rel=":license" href="...">Creative Commons license</a> . To summarise, what I'm saying is that we should tweak the primer and syntax documents so that any usage of XHTML-vocab values have the colon in front. We should send a clear message that *new* mark-up should use this unambiguous method of specifying XHTML-vocab values. Then we can leave the 'legacy question' for another day. :) (Note that to make this work requires just a one-line change in the syntax document, that sets the 'default mapping'.) Regards, Mark -- Mark Birbeck, formsPlayer mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232 http://www.formsPlayer.com | http://internet-apps.blogspot.com standards. innovation.
Received on Thursday, 18 October 2007 10:39:52 UTC