- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Thu, 18 Oct 2007 10:36:00 +0100
- To: "Manu Sporny" <msporny@digitalbazaar.com>
- Cc: "public-rdf-in-xhtml-tf. w3. org" <public-rdf-in-xhtml-tf@w3.org>
Hi Manu, We have for a long time now been talking about the specifics of 'RDFa in XHTML'. Whilst it is certainly the intention that RDFa should be usable in any mark-up language, for a long time now we have narrowed our goals to defining RDFa in the very specific context of XHTML. Once this has been done, it should be quite straightforward to codify the 'general rules' of RDFa. So, we are always dealing with a combination of the general rules that come from RDFa, and the more specific rules that _could_ be derived from the host language. I tried to come up with some terminology a while back to help when we're discussing this, and you'll find the first cut at this here [1]. Some of those in the latter category are quite straightforward, such as using <link> and <meta>. But there were others, like using @class, that although tempting, we stayed away from after deciding that we would have been 'overloading' an HTML feature to mean more than was intended. At least with @rel/@rev--whether used on <link> or <a>--it is clear in the HTML specification that a relationship between two documents is being defined. (And of course, <meta> is just as clear.) The following is a little long, because I've replied to each of your points. But the executive summary is this: Firstly, we are definitely dealing with 'RDF in XHTML', and have been for a long time. This means that we have to be quite careful about using HTML features and interpreting them as RDF, and also when we are considering ignoring a language feature. Secondly, HTML @rel values have a different status to values provided by other taxonomies. So for example, when DC is present, a @profile value should be set--that is required by the HTML 4 spec. This doesn't mean we have to process those values now, but what it does mean is that there is a long-term solution available. And more importantly, what it also means is that any non-HTML values can safely be ignored until the use of @profile is clearly defined...perhaps in RDFa in XHTML version 1.1. :) That leaves us with the problem of what to do with HTML's own values in the current spec, but I'll save that for another post. Thirdly, one of the things we need to solve is whether the rules we are discussing apply to all attributes, or only to @rel and @rev. (You suggest excluding them from the discussion, but that's the very problem we are trying to solve.) The remainder of this post is a set of clarifications on the above points, and responses to some of yours: > > [snip] > > The way I see it, one of the issues is that of parser conformance. Well...it's also about the 'use' of the language. > Are we stating that any RDFa parser that doesn't do this pre-processing > step in @rel and @rev is non-conformant? (I don't like this approach as > it doesn't make sense for any non-XHTML document) > > OR > > Are we stating that in XHTML specifically, an RDFa+XHTML parser MUST > perform the pre-processing step for @rel and @rev? (I'm fine with this) As we've said for a long time now, it's the latter. > In other words - it seems that in this instance, the host XML dialect > has a great deal to do with defining what is and isn't conformant behavior. Of course. > > I suppose what it comes down to is that although you are quite right > > that this is outside the scope of RDFa, it's not outside the scope of > > _RDFa in XHTML_, which is, for the time being, what we are dealing > > with. > > 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 did, many moons ago. :) > > So we actually have three sets of 'legacy' values, in a way: > > > > * those that come from HTML, which can be present without a profile; > > I'm fine with placing these in the "Required for a RDFa in XHTML parser" > category. Those values, just to clarify, would be: > > alternate, stylesheet, start, next, prev, contents, index, glossary, > copyright, chapter, section, subsection, appendix, help and bookmark > > is that correct? Right. Although annoyingly "alternate" is a qualifier, so you have the tricky problem of a space separated list of values, and one of the possible values also has a space in it! But anyway, yes, that's the list, give or take a few extra which might get in there if we agree to move the values that are traditionally in meta/@name, into the same collection. > Should these go in the [default graph], or should these go in an [XHTML > graph]? I would argue that they should go in the latter because they are > outside of the core RDFa processing rules. They are extra processing > rules that are a part of the RDFa in XHTML module. You could do that, but it makes no difference to the problem we're dealing with. Our problem is to define the *syntax* of values in @rel and @rev, and where the generated triples are placed is secondary. For example, we could say that any non-prefixed value in @rel/@rev is simply ignored by RDFa. That doesn't mean we 'lose' the XHTML values like @rel="next", because some pre-processor could come along and simply convert this: <link rel="next" href="..." /> to this: <link rel="xh:next" href="..." /> Actually...it would probably be more precise to say this: <link rel="xhvocab:next" href="..." /> But anyway, the point is that although we might define the rule to be 'all non-prefixed values are ignored by an RDFa processor', the fact that we know we are going to have a pre-processing step of _some_ description means that we can 'rescue' these important values, give them a prefix, and then see them appear in our triple store. Of course, this pre-processing step is not yet defined properly, and that gives us an awkward problem, because we don't quite know for certain how to phrase the RDFa itself in such a way that we know things will work together. That's the core of the discussion we're having, I think--which is not to say that we need to define this pre-processing step before we can proceed, but it does mean that we don't quite know what rule to come up with to filter out values. > Or are we stating that the [default graph] is actually the [default > RDFa+XHTML graph]. I would say so, yes. But as I said, that's not at the heart of the issue we're trying to resolve anyway, so it won't help us solve this. > > * those that come from other taxonomies (like DC) that will be accompanied > > by a @profile value; > > ...in my mind the second category could usefully be placed into the > > triple store too, since they have been clearly defined. In other > > words, due to the presence of @profile they are not the 'spurious' -- > > or 'extra' ;) -- triples that everyone is so keen to avoid. > > While I sympathize with this argument, it is outside of the scope of > XHTML, isn't it? RDFa+XHTML parsers are more than welcome to generate > the triples themselves, but do we want to complicate the parsing rules > by stating that the @profile MUST be read and triples generated for that > profile? You've lost me...what proposal are you talking about? No-one is adding parsing rules. No-one said the @profile must be read. My comments were directed at _your_ point saying that if we don't process Dublin Core vocabularies, why should we worry about processing HTML predicates? I was saying that (a) HTML values are actually defined in the HTML spec, and (b) that I hope that we will _at some point_ process DC values, too. I was saying that the key to both of these is the presence or absence of a @profile value. The 'how' of adding such rules will obviously wait until later. (I then went on to 'anticipate' the argument that often comes up, which is that we are not 'entitled' to process these kinds of values, and I did so by pointing out that if a value is present for @profile we are actually entitled to 'interpret' the values since HTML itself allows this.) > Another point I am attempting to make is that there is a cost to doing > this - and that is added complexity. The biggest detractors of RDFa (and > rightly so) argue that the W3C creates bloated specifications (SOAP > being cited over and over again). I'm afraid that the more an > RDFa-conformant parser has to do, the easier it will be for detractors > to make the argument that RDFa is bloated. The part that would really > sting is that they would be correct. The W3C does generally produce bloated specifications, and if you've seen HTML 5 you'll note that the trend is for even bigger specifications. However, I've had the pleasure of working over the last couple of years with Shane McCarron and Steven Pemberton on a series of much smaller specifications, that provide more modular components that can be used together. So: * there are people who are actively trying to reduce the size of W3C specfications, and increase modularity...it's difficult to get a spec that's smaller than one attribute! (i.e., @role) * no-one is proposing any extra complexity anyway. > > * those that are of other types, like OpenID, and so on. > > Outside of the scope of RDFa and RDFa+XHTML, agreed. But that is in a list of different types of 'legacy metadata'! That was about clarifying the issue, not proposing that we process them. > > I've been looking at this for a little while now, because I've been > > wondering if in making this kind of thing possible, we may find a > > solution to the broader question. (And of course, we may not. :)) > > My fear is that in the name of "backwards compatibility", we are going > to overly complicate the number of reserved values for @rel/@rev as well > as the processing rules for RDFa+XHTML documents. I don't know what you mean by 'complicating the number of reserved values'. I think the _mechanism_ we adopt is the key thing here, not the number of values; whether there are 10 or 20 reserved values doesn't really make much difference. The question is to define what to do with these damned legacy values. :) > I realize that I was primarily the person that was pushing for > orthogonality between @rel/@rev and @property. However, it is making the > RDFa+XHTML processing rules and reserved values far too complicated. I'm not sure where you are directing your fire here, especially since there hasn't been a proposed change to the processing rules on this subject for a while. > Should we constrain the discussion to the following: > > - We are specifically talking about RDFa+XHTML parsers when discussing > backwards compatibility for @rel and @rev. > - These rules do not apply to any other document other than XHTML/HTML. See above. > - We do not bring the legacy @rel/@rev reserved values forward to > @property and @instanceof. That's one of the things that needs to be decided. You can't 'constrain the discussion' on the very issue that needs to be decided. One way to look at this is whether the pre-processor should run on all attributes or only on @rel and @rev. > - Do we really want to start talking about another processing step for > anything with a @profile? We've been talking about a processing step for a long time. It's a catch-all bucket into which we can throw things that we don't quite know how to deal with. That doesn't mean we have to define this processing step--I certainly wasn't trying to. Regards, Mark [1] <http://www.w3.org/2006/07/SWD/wiki/RDFa/ProposedStructure> -- 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 09:36:16 UTC