- From: Sebastian Heath <sebastian.heath@gmail.com>
- Date: Wed, 24 Mar 2010 13:07:56 -0400
- To: public-rdfa-wg@w3.org
[Note: this is a resend since I wasn't subscribed to the right list on my first try.] I'm responding to Manu's twitter call for comment. I've read many of the posts but not all so apologies if any of my points have been covered. I'm all for some mechanism allowing specification of a default prefix. Of the ones discussed, scoped @vocab's appeal to me the most. It's straightforward and doesn't redefine an existing attribute. My experience using the base element - which would give me some semblance of a default namespace but would clobber relative URI's that weren't in RDFa href's - makes me want to separate out the rdfa @'s whenever possible. I am concerned about how any rdfa tokenizing mechanism will overlap with the mechanism for defining new @rel values in HTML5. To be sure, this is one of the weirder parts of the standard. Anybody can stick anything http://wiki.whatwg.org/wiki/RelExtensions and it's a candidate for being an official @rel value. How are parsers going to keep up with that? Let alone distinguish between those values and default values. FYI, this is discussed at section 4.12.3.19 of http://dev.w3.org/html5/spec/interactive-elements.html . Or am I misunderstanding something here? I have also vaguely thought about analogies with xslt extensions. Along the lines of the presence of 'xmlns:rdfa="http://w3.org/rdfa-processor"' allows one to create triples that affect the behavior of the rdfa procesor. Change "rdfa:" to whatever you like so long as it's mapped to a specific uri. So <link rel="rdfa:object" href="http://vocab.org"/> would mean all unprefixed objects would fall into vocab.org . As with all rdfa the default @about is the document itself. In the body of document, blocks can be wrapped in spans (though that seems very ugly). And please understand that I'm writing the above as an RDFa user, not as an experienced W3 standard writer. -Sebastian
Received on Wednesday, 24 March 2010 17:08:30 UTC