- From: Ralph R. Swick <swick@w3.org>
- Date: Thu, 27 Oct 2005 15:14:25 -0400
- To: Jeremy Carroll <jjc@hpl.hp.com>
- Cc: public-rdf-in-xhtml-tf@w3.org
At 03:55 PM 10/26/2005 +0100, Jeremy Carroll wrote:
>In HTML it is normal for any ECMAscript to modify the DOM. What is displayed is the modified DOM rather than the original DOM.
>
>For RDF/A, the reading of the metadata from the unmodified DOM perhaps should be primary. e.g. a naive RDF based implementation of RDF/A would ignore everything except the RDF/A and suck out the triples. This would not work if the metadata was in fact computed by the ECMAscript and then added to the DOM using RDF/A.
yes, good catch.
It would be untenable to require RDF engines to implement
scripting languages in order to retrieve the triples from an
X{,HT}ML document. (1)
We also don't want to open a new form of mischievous behavior
where one RDF graph is given by the unprocessed content of a
document and a different RDF graph is given after script
processing. (Which CC license is the documents real license?).
I believe we need to specify that the triples are those that are
given by the XML _before_ script (and stylesheet) processing.
(1) A requirement to support, e.g. ECMAscript is distinguished
from the scenario proposed by GRDDL [2] where support of
transformation languages is optional. In the GRDDL case,
since a transform is named unambiguously by a URI, a
[RDF/GRDDL] processor can implement well-known transforms
in whatever way it chooses; it need not actually dereference the
transform URI unless it wishes to do so.
[2] http://www.w3.org/TeamSubmission/2005/SUBM-grddl-20050516/
Received on Thursday, 27 October 2005 19:14:38 UTC