- From: Shane McCarron <shane@aptest.com>
- Date: Sun, 14 Aug 2011 13:28:46 -0500
- To: public-rdfa-wg@w3.org
- Message-ID: <4E4813DE.7000407@aptest.com>
I am making the edits necessary to remove @profile processing.... which doesn't turn out to be very difficult. However, there is an issue we had not discussed previously. Host Languages are able to define default collections of IRI mappings, terms, and a default vocabulary. We had done this to date via an RDFa Profile document. Going forward, we *could* just specify any mappings in a Host Language specification and require conforming processors to hard code them. In all likelihood they would have hard coded them in an @profile world anyway. However, we could also require that Host Languages continue to *define* their default settings via an RDFa Profile document. There is nothing inherently wrong with the syntax of an RDFa Profile. What people have objected to is the inline processing of @profile by an RDFa processor. So, I want to propose a couple of options: 1. Retain the RDFa Profile syntax definition. Allow host languages to define default terms, IRI mappings, and/or a vocabulary mapping using that syntax. 2. Allow host languages to define default terms, IRI mappings, and/or a vocabulary mapping, but do not require any machine readable syntax. Implementations would be required to hard-code the definitions. 3. Allow host languages to define IRI mappings and/or a vocabulary mapping. but NO TERMS. Instead, the terms are defined via the vocabulary. Use the proxy vocabulary technique to connect terms to their ultimate definitions (assuming the host language definition is not definitive). I am putting in editor's notes and pressing ahead assuming that option 3 is the least impact option. But if we could discuss it at an upcoming call I would appreciate it. -- Shane McCarron Managing Director, Applied Testing and Technology, Inc. +1 763 786 8160 x120
Received on Sunday, 14 August 2011 18:29:16 UTC