- From: Nathan <nathan@webr3.org>
- Date: Sat, 09 Oct 2010 17:01:32 +0100
- To: Ivan Herman <ivan@w3.org>
- CC: Gregg Kellogg <gregg@kellogg-assoc.com>, RDFA Working Group <public-rdfa-wg@w3.org>
Ivan Herman wrote: > There is also another technical issue that can mud the waters. Imagine a > > <body> > <div profile="myprofile"> > <div rel="NEXT" resource="asfasdfa"/> > </div> > </body> > > and, say, myprofile defines a term for 'next' with > > [ > a rdfa:CaseSensitiveMapping ; > rdfa:term "next" ; > rdfa:onUri "blabla" > ] > > It is not absolutely clear in my mind what would be the property generated for @rel. If there was no profile, NEXT==next, it is the relevant XHTML URI for 'next'. But the profile gives another meaning to 'next' but makes it in a case sensitive way. Would NEXT be mapped against the XHTML URI? Probably yes, but I think it is a bit disturbing for users if these things are messed up, don't you think? What triple would be produced for a @rel of 'next' (the link relation), do we have a URI this resolves to? Assuming the case-insensitivity rules of rel and rev don't affect CURIEs since they resolve to URIs before comparison? (important to clarify this imo) Precedence rules for processing? If the token doesn't match a registered Link Relation in a case insensitive fashion, then check rdfa:terms in a case-sensitive fashion? Appears to me like we can't redefine @rel and @rev to be case sensitive, and we can't define that a plain literal is to be compared in a case-insensitive fashion, and that we'd be unwise to let the link relation of 'next' produce anything other than the expected webscale results. How badly do we need rdfa:term? (assuming quite badly with microformat considerations) TIA, Nathan
Received on Saturday, 9 October 2010 16:02:49 UTC