RE: XSL WG comments on XML Signatures

With respect, Mr. Clark, I don't understand how you can say

1) that Expr is the 'right' entry point for Xpath
2) XSLT uses almost exclusively Expr
3) the XPath transform is legal except for the starting context

and then say

4) the XPath transform is "twisted" and "bizarre"

Those are judgmental words to use.

I submit that implementations MUST be able to handle empty node sets (see
the boolean() function).  What should the context node, context position and
context size be for an empty node set?

It seems counterintuitive that XPath could not handle an empty node-set on
input yet everywhere else in the implementation it would be expected to
handle it.  However, it is only a minor tweak to give it an initial node-set
of some kind, as you pointed out.  How can a minor tweak be twisted and
bizarre?

Finally, there is the issue of why it is put together this way at all, which
I do not think you have given fair consideration.

The WG has defined that all transforms take as input either the result of
the previous transform or the result of the URI-reference.  So, the XPath
transform receives a string of data, which it must convert to a node-set in
order to do what XPath does best.  However, the string received as input may
not be in a form processable by an XML processor-- but it might be close,
and the author of the XPath transform may know how to tweak it so that it is
able to be parsed.

The section of the XSLT spec that you pointed out describes the fact that it
is alright to output a string that is a well-formed external general parsed
entity.  That's fine with me, and the XPath transform user can easily do
this.  In fact, it is the norm if serialize() is called on the resultant
node set (so if XSLT does it, why is it bizarre?).

However, the real issue is what is the most sensible way to add
*function*alility to XPath? The XPath transform needs to convert from string
to data structure on input, and from data structure to string on output
(because these are the rules, and I didn't make them).  I had to add
*function*ality to XPath to accommodate this need, and the most natural way
of doing this was to add to the function library a method parse and a method
serialize.  This also allowed me to fill in some of the gaps that are left
open to the application by the XPath recommendation.

The bottom line is do you accept the fact that it is not twisted or bizarre
to add functionality to XPath by adding functions (which is what XPointer
and XSLT did)?  If instead you recommend that we define parse and serialize
functionality outside of XPath, that is fine by me because the only reason I
added them as functions is because there were complaints about the fact that
XPath didn't do this type of conversion between string and node-set, so it
was bizarre that we would wrap that functionality around XPath.

By the way, the few problems solved by adding serialize and parse as
functions are, in my opinion, not critical.  So feel free to recommend that
we move the parse and serialize as pre- and post-processing steps.  Then, at
least I can do it on *someone's* authority!



functions implies that we can

-----Original Message-----
From: James Clark [mailto:jjc@jclark.com]
Sent: Tuesday, March 14, 2000 5:11 PM
To: Jonathan Marsh
Cc: 'John Boyer'; IETF/W3C XML-DSig WG; w3c-xsl-wg@w3.org
Subject: Re: XSL WG comments on XML Signatures


Jonathan Marsh wrote:

> Yes, Expr could be defined in your spec as the entry point.  In XSLT,
> certain attributes are defined as Expr and others as LocationPath.  It
> should be clarified in the spec exactly which entry point you intend.  I
> assumed LocationPath.

Expr is the right entry point.  There aren't any XSLT attributes that
use LocationPath.  Some use Pattern as an entry point, but that's a
specialization of Expr not LocationPath.

> > From: John Boyer [mailto:jboyer@PureEdge.com]
> > As to your assertion that this application is 'odd', it does
> > not seem that
> > the authors of XPath share your opinion since they have
> > specified the XPath
> > root language symbol as Expr and not LocationPath.  You are
> > entitled to your
> > opinion, but here is why I put it together in the way I did:
>
> XPath states: "Expression evaluation occurs with respect to a context. ...
> The context consists of: a node (the context node); a pair of non-zero
> positive integers (the context position and the context size) ..."
>
> Thus the context position and context size may not be set to zero, and it
is
> a reasonable assertion that the context node may not be omitted (a null
> context node doesn't seem like a context node to me).  I think this goes
> beyond "odd".

On this one, I agree with Jonathan.  There is no provision in XPath for
the context node to be null.  The semantics of the language are not
well-defined in this case.  This is easily avoided: just define it to be
a root node with no child nodes.

> > 1) Everything I did in specifying the XPath transform is a
> > kind of extension
> > that is permitted by the XPath recommendation.  So, for
> > example, I created
> > the functions parse() and serialize() because the transform needed
> > additional *function*ality, so rather than just making up
> > whatever I needed,
> > I specified it in terms of a function library addition, which
> > is permitted
> > by XPath.
>
> I'll grant you that these are legal in an Expr,

Apart from the null context node, it does appear to be legal.

> but not that this will be a
> familiar use of XPath to users.

It seems very bizarre to me.

> > 2) In my original design, I did as you suggested by putting the parsed
> > version of the input as the context node.  However, there
> > were some nagging
> > little problems where people wanted to start with a fragment
> > of XML, then
> > transform.

I don't see why that should be problem.  XSLT works on fragments just
fine: see
http://www.w3.org/TR/xslt#root-node-children

This approach would be much, much better.  I would suggest we try and
work out the problems you encountered with this approach.

> > Unfortunately, we don't have XML processors that
> > work on XML
> > fragments.

Why does that force you to incorporate XPath in a twisted way?

James

Received on Wednesday, 15 March 2000 12:31:53 UTC