Re: Proposed changes to address issue-dbooth-3 (ambiguity)

Technical point - no advocacy.

I have constructed a test that has visibly different results.

See
http://www.w3.org/2001/sw/grddl-wg/td/pendinglist#comments
(six tests, one input document)

The following tests are, I believe, consistent with the current design:
http://www.w3.org/2001/sw/grddl-wg/td/pendinglist#db-3a
http://www.w3.org/2001/sw/grddl-wg/td/pendinglist#db-3c

Those are also valid with the proposed change.
In addition the following alternate tests are also valid with the 
proposed change:
http://www.w3.org/2001/sw/grddl-wg/td/pendinglist#db-3b
http://www.w3.org/2001/sw/grddl-wg/td/pendinglist#db-3d
http://www.w3.org/2001/sw/grddl-wg/td/pendinglist#db-3e
http://www.w3.org/2001/sw/grddl-wg/td/pendinglist#db-3f


The input document is:
http://www.w3.org/2001/sw/grddl-wg/td/db.xml
i.e.
<!DOCTYPE db SYSTEM "db.dtd">
<db
    xmlns:g = "http://www.w3.org/2003/g/data-view#"
    g:transformation = "db1.xsl"
    />

The external DTD has the following contents:

<!ELEMENT db EMPTY>
<!ATTLIST db xmlns
     CDATA #FIXED "http://www.w3.org/2001/sw/grddl-wg/td/dbns#">
<!ATTLIST db xmlns:g
     CDATA #FIXED "http://www.w3.org/2003/g/data-view#">
<!ATTLIST db g:transformation
     CDATA #IMPLIED >

This means that when read with a validating parser, the document has a 
namespace, and the rules for a GRDDL namespace transformation apply.
Thus when read with a validating parser (cases #db-3c #db-3d #db-3e 
#db-3f) two transforms apply db1.xsl and db2.xsl.

When read with a non-validating parser (cases #db-3a #db-3b) only one 
transform applies db1.xsl.

db1.xsl and db2.xsl are very similar.
This is the heart of db1.xsl
   xmlns:d = "http://www.w3.org/2001/sw/grddl-wg/td/dbns#"

   <xsl:template match="/d:db">
     <rdf:RDF>
        <rdf:Description rdf:value="validated input to db1"/>
     </rdf:RDF>
   </xsl:template>
   <xsl:template match="/db">
     <rdf:RDF>
        <rdf:Description rdf:value="not validated input to db1"/>
     </rdf:RDF>
   </xsl:template>

Thus the transform emits one triple, which differs depending on whether 
the input to the transform was validated or not.

Case #db-3a illustrates the case when a non-validating parser is used, 
so that only db1.xsl is found, and then the second rule matches, but not 
the first.

Case #db-3c illustrates the case when a validating parser is used, so 
that both db1.xsl db2.xsl apply, and then the first rules match, but not 
the second.

In the Candidate Rec design, the XPath nodeset used to find the 
transforms is the same as the XPath nodeset passed to the XSLT. Thus 
these two results exhaust the possibilities.

In the proposed changed design, the document D (before parsing) is 
passed to each transform. Thus each transform parses the input, and the 
decisions about whether to use a validating parser or not are 
independent of each other, so that the other cases listed are all legal 
(if hard to implement - one could choose a validating parser or not, as 
a result of a random number generator - one could always apply 
transforms both to validated and non-validated input).


Jeremy



-- 
Hewlett-Packard Limited
registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Tuesday, 19 June 2007 07:54:32 UTC