ISSUE-1: JSONP as a vocabulary encoding format

(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/

Received on Tuesday, 9 March 2010 04:57:27 UTC