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

Jeremy,

Sorry I missed this message earlier this morning.  I'm glad John
mentioned it.

This is an excellent example.  It nicely illustrates what the proposed
change is *not* attempting to do.  The proposed change is *not*
attempting to *prevent* document authors or GRDDL transformation authors
from intentionally producing variable results if they wish.  Indeed, as
you and others have pointed out on other occasions, variable results may
be *desirable* in some cases.  Rather, the proposed change permits the
variability to be reduced in cases where that variability is *not*
desirable and the GRDDL transformation author wishes to reduce it.  This
is a critical distinction.

In the example below, the DTD clearly shows that this document was
designed with GRDDL in mind and hence was *designed* to produce this
variability.



David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Opinions expressed herein are those of the author and do not represent
the official views of HP unless explicitly stated otherwise.
 

> -----Original Message-----
> From: Jeremy Carroll [mailto:jjc@hpl.hp.com] 
> Sent: Tuesday, June 19, 2007 3:51 AM
> To: Harry Halpin
> Cc: Booth, David (HP Software - Boston); GRDDL Working Group
> Subject: 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>
> 
> 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).

Received on Tuesday, 19 June 2007 13:50:12 UTC