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 11:01:27 UTC