- From: Innovimax SARL <innovimax@gmail.com>
- Date: Mon, 29 May 2006 10:22:04 +0200
- To: "Jeni Tennison" <jeni@jenitennison.com>
- Cc: public-xml-processing-model-wg@w3.org
- Message-ID: <546c6c1c0605290122w449dec1m5f3da2e1a6d7782e@mail.gmail.com>
Hi Jeni,
On 5/29/06, Jeni Tennison <jeni@jenitennison.com> wrote:
>
> Hi Mohamed,
>
> Innovimax SARL wrote:
> > On 5/28/06, *Jeni Tennison* <jeni@jenitennison.com
> > <mailto:jeni@jenitennison.com>> wrote:
> > Innovimax SARL wrote:
> > > Ok, you're right, it is an valid XPath 1.0 expression, but not a
> > *usual*
> > > XPath 1.0/XSLT 1.0 construction, because the variable is a
> > "result tree
> > > fragment" and cannot be bound to a nodeset in XSLT 1.0 (but in
> > XSLT 1.1
> > > and later).
> >
> > Again, I wrote it too fast
> > I wanted too say << because the variable COULD be a "result tree
> > fragment" >>
> > in the case of an inline document like this as already been proposed by
> > Norm in [1]
> >
> > <p:step name="p:xslt">
> > <p:input name="document">
> > <doc>
> > <p>Some data</p>
> > </doc>
> > </p:input>
>
> This would only result in a result tree fragment if that's how we
> defined <p:input> to work. I'd strongly suggest that we said that if
> there was (an element) content to <p:input> then the input was set to a
> new document with a copy of the content of <p:input> as the content of
> the document. We don't have any need for the concept of "result tree
> fragments" (which are a purely XSLT 1.0 invention).
>
> > And another problem for me is that, it was said that variable in Xproc
> > could be only Strings....so I cannot understand how they could be bound
> > to NodeSet !!
> >
> > [1]
> >
> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Apr/0067.html
>
> [I think that you've referenced the wrong mail here: I can't see
> anything in this mail that talks about the values of variables (it's a
> mail about directed vs. generic syntax).
The email reference was just here for the use of "inline" documents
]
>
> I think that we've agreed that *parameters* should only take string
> values, but have said nothing about the values that XProc variables can
> be set to. I think it would be a mistake to allow them to only be bound
> to strings, because it's quite common to want to set a variable to an
> element and set other variables (or parameters) based on information
> about that element.
>
> For example [here using your favoured syntax]:
>
> <p:variable name="glyphInfo" context="manifest"
> select="/glyphs_manifest/glyph[@filename = $filename]" />
> <p:variable name="glyphMnemonic"
> select="$glyphInfo/@mnemonic_string" />
> <p:variable name="glyphHeight"
> select="$glyphInfo/@height" />
>
> It would be a lot more tedious to have to write:
>
> <p:variable name="glyphMnemonic" context="manifest"
> select="/glyphs_manifest
> /glyph[@filename = $filename]
> /@mnemonic_string" />
> <p:variable name="glyphHeight" context="manifest"
> select="/glyphs_manifest
> /glyph[@filename = $filename]
> /@height" />
The difference here between the two notations is not that big and I still
prefer the second
In any case, even if the values of XProc variables (defined with
> <p:variable>) elements can only be set to strings, this has no bearing
> on whether we use <p:input> to bind XPath variables to node-sets (of
> root nodes).
>
> > In fact that's why i'm againt use of $var construct
> >
> > because instead of making a $var and using it a lot latter
> >
> > I would wrote it, without variable,
> > <p:step name="my:process">
> > ...
> > <p:param name="stylesheet-pi" context="doc"
> > select="/processing-instruction('xsl-stylesheet')" />
> > ...
> > </p:step>
> >
> > which is for me a lot clearer (as user and as implementor)
>
> OK, here's a more realistic example in your favoured syntax:
>
> [snip]
If you really don't think that the uses attributes in the above are an
> unnecessary burden on users then we'll have to agree to differ.
I think we have two different kind of concepts :
* The "context" attribute which tell against which documents the xpath is
being evaluted
* The "uses" attribute which tell us about hidden dependencies, which are
not explicit in the "context" attribute
(Note : please not the quotes, because i'm not sure this wording will
convince everyone)
These two attributes should take a list of qnames refering to *DOCUMENTS*
If they gave too much burden, I can imagine to let the "uses" attribute
implied in variable declaration, but mandatory everywhere else
so in your example
<p:choose>
<p:input name="input" ref="document" />
<p:output name="output" ref="result" />
<p:variable name="xsl-stylesheet-pi"
context="input" -- instead of uses="input" --
select="/processing-instruction('xsl-stylesheet-pi')" />
<p:variable name="stylesheet-type-data"
context="" -- empty document so could be implied --
uses="input" -- even if the reference to input is implicit
here,instead of uses="xsl-stylesheet-pi" which is NOT a document, but it
could just be implied in variable --
select="substring-after($xsl-stylesheet-pi, 'type=')" />
<p:variable name="stylesheet-type-quote"
uses="input" -- same as above, could be implied --
select="substring($stylesheet-type-data, 1, 1)" />
<p:variable name="stylesheet-type"
uses="input" -- same as above, could be implied --
select="substring-before(
substring($stylesheet-type-data, 2),
$stylesheet-type-quote" />
<p:when uses="input" -- same as above, but it is MANDATORY here --
test="$stylesheet-type = 'text/xsl'">
<p:variable name="stylesheet-href-data"
uses="input" -- same as above, could be implied --
select="substring-after($xsl-stylesheet-pi,
'href=')" />
<p:variable name="stylesheet-href-quote"
uses="input"
select="substring($stylesheet-href-data, 1, 1)" />
<p:variable name="stylesheet-href"
uses="input"
select="substring-before(
substring($stylesheet-href-data, 2),
$stylesheet-href-quote)" />
<p:step name="p:load">
<p:param name="href" uses="input" -- mandatory --
select="$stylesheet-href" />
<p:output name="output" label="stylesheet" />
</p:step>
<p:step name="p:xslt">
<p:input name="input" ref="input" />
<p:input name="stylesheet" ref="stylesheet" />
<p:output name="output" label="result" />
</p:step>
</p:when>
<p:otherwise>
<p:step name="p:xslt">
<p:input name="input" ref="input" />
<p:input name="stylesheet" href="default.xsl" />
<p:output name="output" label="result" />
</p:step>
</p:otherwise>
</p:choose>
So after cleaning it from the comments
<p:choose>
<p:input name="input" ref="document" />
<p:output name="output" ref="result" />
<p:variable name="xsl-stylesheet-pi"
context="input"
select="/processing-instructio n('xsl-stylesheet-pi')" />
<p:variable name="stylesheet-type-data"
uses="input"
select="substring-after($xsl-stylesheet-pi, 'type=')" />
<p:variable name="stylesheet-type-quote"
uses="input"
select="substring($stylesheet-type-data, 1, 1)" />
<p:variable name="stylesheet-type"
uses="input"
select="substring-before(
substring($stylesheet-type-data, 2),
$stylesheet-type-quote" />
<p:when uses="input"
test="$stylesheet-type = 'text/xsl'">
<p:variable name="stylesheet-href-data"
uses="input"
select="substring-after($xsl-stylesheet-pi,
'href=')" />
<p:variable name="stylesheet-href-quote"
uses="input"
select="substring($stylesheet-href-data, 1, 1)" />
<p:variable name="stylesheet-href"
uses="input"
select="substring-before(
substring($stylesheet-href-data, 2),
$stylesheet-href-quote)" />
<p:step name="p:load">
<p:param name="href" uses="input"
select="$stylesheet-href" />
<p:output name="output" label="stylesheet" />
</p:step>
<p:step name="p:xslt">
<p:input name="input" ref="input" />
<p:input name="stylesheet" ref="stylesheet" />
<p:output name="output" label="result" />
</p:step>
</p:when>
<p:otherwise>
<p:step name="p:xslt">
<p:input name="input" ref="input" />
<p:input name="stylesheet" href="default.xsl" />
<p:output name="output" label="result" />
</p:step>
</p:otherwise>
</p:choose>
so there is not so much burden IMO
> I understand that we want to make things simple for the
> implementation,
> > but I think forcing the user to make the dependencies explicit is a
> > real
> > burden on the user for something that's relatively easy for the
> > implementation to work out for itself (all the implementation needs
> to
> > do is match the XPath expression with the regular expression
> >
> > ([^$'"]|('[^']*')|("[^"]*"))*\$(\i\c*)
> >
> > and get the values of the fourth subexpression of each of the
> matches).
> > Generally, I am against forcing the user to make explicit things
> that
> > the implementation can work out for itself.
> >
> >
> > I'm not sure a simple regex will be sufficient and what about case like
> > $a/b[@d=$b/@d and @e=$c/@e]
>
> Please see the attached XSLT 2.0 stylesheet, which takes an XPath
> expression as a 'xpath' parameter and gives you a list of the variables
> on which the XPath depends. It uses the regular expression that I gave
> above to identify the variable references in the XPath expression.
You were right once more !
But what about, document() function or context() function in a p:for-each or
any other nasty construction...
Cheers,
>
> Jeni
> --
> Jeni Tennison
> http://www.jenitennison.com
>
>
>
Cheers,
Mohamed
--
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 8 72 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €
Received on Monday, 29 May 2006 08:22:13 UTC