Loading tokens via @profile and XMLHttpRequest issues

During the last telecon, Ben raised two very important issues that we
had not previously discussed concerning the "loading vocabularies via
@profile" discussion.

Note that this has nothing to do with mapping prefixes via
@token/@prefix/@xmlns: - that is a separate issue.

This issue has to do with pre-loading a list of vocabulary prefixes or
terms that may be used by the RDFa processor to expand CURIEs. So, this
mechanism would allow us to have markup like the following:

<div profile="http://example.org/vocab#" about="#ian">
...
   <span property="name">Ian Hickson</span>
...
</div>

which would generate the following triple:

<#ian> <http://xmlns.com/foaf/0.1/name> "Ian Hickson" .

The RDFa processor would do the following to generate the triple above:

1. Upon detecting @profile, the RDFa processor would load, process and
   store all triples generated from "http://example.org/vocab#" in an
   separate graph (let's call it graph V) from the current page's
   triples.
2. When @property is detected, it would attempt to resolve "name" via
   the RDFa processing rules as defined in XHTML+RDFa. If "name" cannot
   be resolved, it would then use graph V to resolve the "name" value.
   Graph V would have a mapping from "name" to
   "http://xmlns.com/foaf/0.1/name".
3. The final triple would be generated.

Ben's primary concern, which I agree with very strongly, is that if
"http://example.org/" is a remote site, that the mechanism used to load
the remote vocabulary is unimplementable via Javascript. It violates the
same-origin security check for XMLHttpRequest[1]. This is a deal-killer
since we want to support Javascript implementations and implementations
in other languages that may require some sort of similar same-origin
security check.

There are still alternatives to Mark's proposal - none of these are great:

Alternative #1: @profile restricted to local vocabulary documents
-----------------------------------------------------------------

The rules would be the exact same as those specified above, but we would
require that the vocabulary document should be downloaded and stored on
the same site. So, this would then become the markup:

<div profile="/vocab#" about="#ian">
...
   <span property="name">Ian Hickson</span>
...
</div>

Alternative #2: @profile is optional for conformance
----------------------------------------------------

We could allow non-same-origin URLs in @profile, but not require all
parsers to dereference the non-same-origin @profile to be conformant
parsers. This would mean that Javascript processors may not generate as
many triples as processors that are capable of dereferencing
non-same-origin URLs.

Alternative #3: Lazy @profile dereferencing (Ben's proposal)
------------------------------------------------------------

We could not dereference @profile in the RDFa processor, but rather use
the contents of @profile to generate triples. The triples would then be
dereferenced at a later time. So, if we have this markup:

<div profile="http://example.org/vocab#" about="#ian">
...
   <span property="name">Ian Hickson</span>
...
</div>

the following triple would be generated (note the predicate):

<#ian> <http://example.org/vocab#name> "Ian Hickson" .

It would be an application processors job to dereference
"http://example.org/vocab#name" at a later time and map the URL to
"http://xmlns.com/foaf/0.1/name". However, this would still mean that
you couldn't have a pure Javascript implementation since the Javascript
post-processor would need to dereference "http://example.org/vocab#name"
- which violates the same-origin check in XMLHttpRequest[1].

Alternative #4: Forget About Javascript and XSLT
------------------------------------------------

I don't believe this line of argumentation, but I'm including it for
completeness. There may never be "serious" implementations of RDFa
frameworks in Javascript. Microformats suffer from the same
implementation issues. The XMDP profiles[2] that people are supposed to
be using in their Microformatted documents cannot (in some cases) be
dereferenced via XMLHttpRequest. Rather than have one or two
implementation languages constrain an important RDFa feature, we could
opt to not support environments that are incapable of loading
non-same-origin URLs.

-- manu

[1]http://www.w3.org/TR/XMLHttpRequest/#open
[2]http://gmpg.org/xmdp/
[3]http://microformats.org/wiki/xmdp-faq

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Released - Browser-based P2P Commerce
http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/

Received on Thursday, 6 August 2009 04:39:06 UTC