W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > March 2010

Re: Another way other than @profile, @vocab or @map

From: Shane McCarron <shane@aptest.com>
Date: Fri, 19 Mar 2010 11:13:47 -0500
Message-ID: <4BA3A2BB.8020901@aptest.com>
To: martin@weborganics.co.uk
CC: Toby Inkster <tai@g5n.co.uk>, Ivan Herman <ivan@w3.org>, RDFa WG <public-rdfa-wg@w3.org>
Thoughts below:

Martin McEvoy wrote:
> there is a flaw in with the above approach of course, which I guess is 
> why the whole discussion of  RDFa profile's as a method of declaring 
> prefix-less tokens.
> example:
> <body vocab="http://www.w3.org/2006/vcard/ns#">
>     <div typeof="VCard" about="">
>         <div property="fn">Fred</div>
>         <a rel="url me" href="http://fred.example.com/">Home</a>
>     </div>
> </body>
> the @rel value "me" is not a part of the vcard vocabulary, the parser 
> doesnt know that, How can a RDFa parser tell the difference between a 
> "qualified name" and some other name not included in the vocab?

I don't really feel this is an issue.  If you want to validate it, you 
*could* retrieve the document and look for keyword definitions in the 
default graph (following your nose to other referenced vocabularies if 
needed), but who cares?  Seriously.  This is no different than saying 
@rel="foo:bar".  Who is to say there is a term 'bar' within 'foo'?  
Well, I did.  Just now.  When I referenced it.  Today we provide some 
level of checking to ensure that our predefined keywords are used and 
others are not.  I feel it would be fine to loosen the rules on parsers 
when you have changed the default vocabulary.  In that instance, we 
trust the author to use terms but permit 'validating parsers' to attempt 
to do further validation and throw exceptions of they choose.  This is 
the same thing XML does for its parsing rules.

Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Friday, 19 March 2010 16:14:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:17 UTC