Re: RDFa test case #1 missing @profile?

Comments below:

Norman Walsh wrote:
> / Shane McCarron <shane@aptest.com> was heard to say:
> | Just a little more data here.  Every XHTML family markup language,
> | including XHTML+RDFa, has a version attribute on the html element.
> | This attribute has a predefined, FIXED value for each language.  If
> | what you are concerned about is announcement, and I know that I am, a
> | great way to announce your intention would be:
> |
> | <html version="XHTML+RDFa 1.0" ... >
>
> Yes, I suppose that's sufficient. I get the impression that no attempt
> to persuade the working group to add a statement along the lines
> "In order to be interpreted as RDFa, a document MUST have {some explicit
> marker}", no matter how passionate, would succeed.
>   
To be fair, this specification ONLY defines XHTML+RDFa, so it really 
only mandates that triples are extracted from XHTML+RDFa conforming 
documents.  If a processor happens to pull triples from other documents 
(mine doesn't for what its worth) they are going beyond the mandate.  
But the task force was careful not to prohibit this because we envision 
uses beyond XHTML+RDFa in the future.  I for one appreciate your concern 
that a rogue RDFa processor could grab unintended triples from random 
documents.  We have attempted to minimize the possibility of this by 
eschewing the use of existing attributes as triggers for triple 
generation.  Not to belabor this point, but do you really think there 
are documents in the wild that use attributes like the ones we have 
defined AND scoped values (CURIES)?  Without that combination, I don't 
see any rogue triples being generated anyway.

Would you be open to the converse requirement?  Not speaking for the 
task force, just spitballing, and wording to be massaged, but:

A conforming RDFa processor MUST extract triples from any document that 
uses the DOCTYPE declaration, @version, or @profile values defined herein.

Document authors who wish to ensure their triples are extracted SHOULD 
use one of these declaration methods.

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Monday, 3 March 2008 22:17:44 UTC