Re: Loading tokens via @profile and XMLHttpRequest issues

I am not a Javascript implementer. Theoretically, the server-side and
python based implementation of mine could be extended to handle the
complete roundabout approach, ie, getting the @profile from somewhere,
extract the RDF triples, etc. Nevertheless, I believe this would make
the whole implementation way more complicated. In general, one may have
to re-engineer the implementation to allow for some sort of a recursive
setup (after all, @profile may lead to an RDFa document that can also
include @profile...), the implementation should include a complete RDF
processing with parsers and the proper management of independent RDF
graphs, etc. None of these are impossible of course, but we would turn
the implementation of RDFa from a relatively simple process to a much
more complex project, which beats the purpose in my view....

Just an implementer's feedback!

Ivan

Manu Sporny wrote:
> 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
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf