- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Fri, 12 Oct 2007 11:23:35 -0400
- To: "public-rdf-in-xhtml-tf.w3.org" <public-rdf-in-xhtml-tf@w3.org>
Mark Birbeck wrote: > I disagree that there is no issue here, and I'd certainly like for > triples to be generated by the following mark-up: > > <link rel="next" href="..." /> > <link rel="prev" href="..." /> > > Lots of nice things can be done with this data. I'm sure there are! :) I believe I failed to mention my point, or didn't construct the argument in a way that was useful. The way I see it, one of the issues is that of parser conformance. 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) 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. > 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... > 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? 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. Or are we stating that the [default graph] is actually the [default RDFa+XHTML graph]. > * 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? 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. > * those that are of other types, like OpenID, and so on. Outside of the scope of RDFa and RDFa+XHTML, agreed. > 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 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. 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. - We do not bring the legacy @rel/@rev reserved values forward to @property and @instanceof. - Do we really want to start talking about another processing step for anything with a @profile? -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Bitmunk Launches World's First Open Music Recommendation Service http://blog.digitalbazaar.com/2007/09/09/bitmunk-music-recommendation/
Received on Friday, 12 October 2007 15:23:48 UTC