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
smime.p7s
Description: S/MIME Cryptographic Signature
