Re: capturing reserved keywords in @rel

Mark,

I think I understand but, as an implementer, I am still scared.

What this means is that if tomorrow the society for 
underwater-basket-weaving successfully registers a new @profile by W3C, 
defining new @link values for XHTML beyond the familiar 'next', 
'previous', 'license', etc, controlled by the XHTML group, then my 
implementation must understand the underwater-basket-weaving-link-values 
in their namespace right away to stay conformant. Ie, unless I make 
manual updates (tiny update that might be with a built-in preprocessing 
architecture), this means that the RDFa implementation cannot follow its 
nose to do that. Indeed, it would need (1) a formal and machine-readable 
way to describe those attributes somewhere (2) the implementation 
automatically follows the @profile value, extract the necessary 
information to handle those attributes (somehow)....

In other words, I would prefer not to have any reference to @profiles at 
all, just rely on the one and fixed XHTML link set in RDFa.

Ivan

Mark Birbeck wrote:
> Hi Ivan,
> 
>> I do not think there should be _any_ reference to _any_ preprocessing
>> step in RDFa. Yes, @rel="DC.Creator" will be lost...
> 
> Yes...that's exactly what I said, too. :) I'm not at all proposing
> that we support other legacy values now, but I raised it because I
> think we should somehow integrate our solution to the @rel value
> problem into the general notion of @profile, rather than it being
> something vague and non-XHTML.
> 
> So in XHTML, the spec already says that if you don't have a profile
> for your @rel values, then unrecognised ones are ignored. I'm
> suggesting that we leverage that by saying in a note that the
> unrecognised values are actually discarded...we don't know how it's
> done, but then the current HTML/XHTML documents don't say how it's
> done either. :)
> 
> Now, we know in our 'meta world' sitting outside of the syntax
> specification, that we _do_ actually know how the values will get
> discarded -- we'll probably use a preprocessing step to do it. But
> since we don't want to put that in the spec, the best we can do is put
> a note into the spec that says something like:
> 
>   Normal @profile behaviour should still be observed, which means that @rel
>   values that are not in the list of LinkTypes, and have not been made
>   available via a profile, have no meaning. In an RDFa environment values
>   in @rel that do conform to specified profiles should be treated as CURIEs,
>   and placed into the appropriate namespace.
> 
> We don't say how to do this...we don't even mention a processor at
> all. So for some implementers they might do this by doing the test
> when processing @rel, others might do it like Ben has done, and run an
> initial pre-processing step.
> 
> But the main point is that we have not changed the spec in relation to
> CURIEs, and essentially the processing of @rel is no different to that
> for @about. (It just so happens that certain kinds of values will
> never reach the RDFa processor.)
> 
> Does that clarify what I'm getting at? The key thing is the note,
> which needs to ensure that implementers know that something needs to
> be done, but doesn't prescribe how, and at the same time, by referring
> to @profile it is firmly grounded in existing XHTML concepts.
> 
> Regards,
> 
> Mark
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf