(co-chair hat off)
After quite a bit of reflection on the JSON/JSONP thing, I'm finding
myself less and less supportive of that direction for the following
reasoning:
If the whole purpose of the JSON/JSONP encoding is to enable usage of
RDFa in browsers that don't support CORS /AND/ don't support the RDFa
API, I think we may be making a design mistake based on a short-term
browser issue. That issue being the lack of 100% coverage of CORS in
browsers.
There are currently two ways to solve the "loading remote vocabulary" issue:
1. Use CORS - which is implemented in the latest version of Firefox,
WebKit and Internet Explorer.
2. Use the RDFa API - which, in the very worst case, never gets traction.
CORS will eventually be in all web browsers. I can't foresee why the web
authoring community at large would reject the technology - it allows
many great new Javascript mash-ups to occur. If the RDFa API is
successful, that will almost ensure that dereferencing vocabulary
profiles will be natively supported in browsers.
I would argue that the probability that both 1 and 2 will happen with
varying degrees of success are highly probable within the next 5 years.
If we implement JSONP, that particular technology won't make much sense
after #1 or #2 gain widespread use, and worse - we will not be able to
get rid of it in RDFa. It'll be a vestigial feature that was in use from
2011-2016 and then hangs on for far longer than we would want it to hang
on in the name of backwards compatibility.
I also agree with Ivan's take on using vocabularies to provide RDFa
processing rules (such as defining prefixes and tokens). We ensured that
rdf:XMLLiteral should be processed differently than plain literals, and
we're using an RDF vocabulary to provide that hint. I see no compelling
reason why other vocabularies couldn't give the RDFa processors rules on
which tokens and prefixes should be defined in vocabulary documents.
Especially if a vocabulary was designed to augment the RDFa processing
algorithm.
I certainly understand that this goes against the general rule of not
mixing markup with processing instructions, but that ship sailed long
ago when we stated that rdf:XMLLiteral should be treated differently.
The thing that should concern us is whether or not using rdfa:prefix and
rdfa:reserved (or something to that effect) will cause authoring
headaches or non-deterministic parser issues. I don't think we're in
danger of either one.
Conversely, using xmlns: to define prefixes and tokens is not a good
design direction. In this case we certainly are doing something that
will cause authoring headaches. Namely, everyone that does a good job of
annotating their vocabulary with OWL/SKOS/RDFS/etc. will run the risk of
those prefixes being leaked from the vocabulary document to the author's
document.
-- manu
--
Manu Sporny
President/CEO - Digital Bazaar, Inc.
Establishing an Open Digital Media Commerce Standard
http://blog.digitalbazaar.com/2009/09/28/a-digital-content-commerce-standard/