- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Fri, 4 Jan 2013 19:18:35 -0500
- To: "shane@aptest.com" <shane@aptest.com>
- CC: Ivan Herman <ivan@w3.org>, Niklas Lindström <lindstream@gmail.com>, RDFa Working Group <public-rdfa-wg@w3.org>
> On Fri, Jan 4, 2013 at 2:17 PM, Gregg Kellogg <gregg@greggkellogg.net> wrote: > > > > The only question I have is: link uses @rel in HTML; is that allowed for a Lite? I would think yes, but this may have to be written down somewhere... > > I would say that the use of @rel in <link> is not part of RDFa Lite, if the values of the @rel attribute would be interpreted by an RDFa processor. In other words, they can have terms which are ignored, but not CURIEs or IRIs. > > > I am forced to disagree. We have no way of constraining an RDFa Processor to only do things in a Lite context or a non-Lite context. Consequently, any occurrence of @rel is going to be interpreted by a conforming processor. And one conforming Processor cannot work differently than another with regard to the (minimal) triples generated, so all of the values of @rel are going to be processed. You're absolutely right that a conforming processor will interpret @rel as it would be anywhere else; it's just that, as a publishing profile, the use of @rel for RDFa Lite markup is not described, and I don't think it should be in the case of <link> either. Therefore, anyone trying to publish HTML5 with RDFa Lite using the <link> element shouldn't use @rel for RDFa markup; this may mean that @rel is used for other purposes, for which we already have text in RDFa Core to support. > In theory a validator could flag the use of @rel on a <link> element, but why? @rel is legal everywhere according to RDFa Lite. At least that is my reading of the Profile. Ivan may do something like this in his processor, as I believe he outputs warnings when non-RDFa Lite is detected; I don't know what he does in the case of @rel for non-RDFa usage, though. Gregg > -- > Shane P. McCarron > Managing Director, Applied Testing and Technology, Inc.
Received on Saturday, 5 January 2013 00:19:18 UTC