- 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