RE: XSL WG comments on XML Signatures

> -----Original Message-----
> From: John Boyer [mailto:jboyer@PureEdge.com]

> The primary use in both XSLT and XPointer is to locate nodes 
> relative to a
> context node, and thus the LocationPath assumes special 
> importance.  As a
> constrained version of Expr, it always returns a nodeset 
> given a context
> node.  It seems to me your problem also could benefit from 
> LocationPaths.
> 
> <John>
> The usual scenario for the XPath transform is to parse the 
> input and obtain
> a node-set for serialization.  Therefore it does benefit from 
> LocationPaths
> because they can be used within an Expr.
> </John>

James has pointed out my brain lapse.  XSLT uses Expr throughout, but
restricts the returns to nodesets in some places, which is not quite the
same as a LocationPath.  XPointer has a similar restriction, Expr is used,
but returns are restricted to nodesets.

> 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".
> 
> <John>
> So, now it's not simply odd, it's beyond odd!  That's 
> interesting.  Let me
> get this right.  It's not odd for XSLT to hi-jack the defined 
> language start
> symbol in XPath, but it is *beyond* odd to use an empty node-set as a
> starting context (given that the variable bindings and 
> function library
> provide a way to create a node-set when needed).
> 
> I'm sorry but this sounds like a lot of knit-picking when the 
> reality is
> that you simply read the document the way I read it at first 
> and assumed
> that everything started with LocationPath, and the authors of 
> XPath simply
> did not design it that way (and they seemed to have reason 
> for this given
> that XSLT uses Expr as a basis in many places).
> 
> As for the starting context of the XPath transform, 
> disallowing an empty
> node-set in the starting context is clearly a minor oversight 
> on the part of
> the authors of XPath.  

Whether it is an "oversight" or not (I don't believe it is) doesn't matter
at this point.  The XPath recommendation clearly precludes null, 0, 0.  Thus
your formulation becomes an "extension to XPath" rather than an "application
of XPath".  It's up to you to decide which is more appropriate in your case.
There are compelling reasons to be simply an application.

> It is necessary for XPath 
> implementations to be able
> to handle empty node-sets.  Check for example the result of 
> the boolean()
> function applied to a node-set.  It is true iff the node-set 
> is non-empty.
> Therefore, empty node-sets must exist.  What do you suppose 
> the context
> node, position and size should be for empty node-sets?  null, 0 and 0.
> </John>

> > 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.  Unfortunately, we don't have XML processors that
> > work on XML
> > fragments.
> 
> Do you mean multiple top-level elements?
> 
> <John>
> Yes, you may have multiple elements as the result of a 
> previous operation,
> or you may simply want to add encoding information and a byte 
> order mark to
> the front of some UTF-16 markup that would not otherwise parse.
> </John>

I think XPath could handle the multiple top-level elements.  The data model
at http://www.w3.org/TR/xpath#root-node doesn't explicitly state that a root
node cannot have more than one element child.  The syntax doesn't make any
assumptions about the uniqueness of the document element either - "/*[2]" is
a legal XPath, although it returns an empty nodelist for a normal XML
document.

> > So, by making a function parse(), it seemed easy
> > to prepend an
> > XML declaration (and a byte order mark, if needed) using
> > string functions
> > available in XPath, then parse the result and use the output
> > node-set in
> > further location steps.
> 
> I'm not completely familiar with your scenario, but doesn't 
> this allow the
> user to prepend any old byte order mark and declaration, even 
> if they don't
> accurately describe the XML data?  If they aren't prepended 
> correctly, a
> parse error could result, right?  It appears that the 
> encoding and BOM are
> available as variables, so is it the case that an author must 
> prepend these
> variables only (and always) in order for the parse to be 
> successful?  Why
> can't this be automated?
> 
> <John>
> Yes, they can produce an error if they do it wrong, but it 
> isn't like anyone
> is ever going to successfully create a signature from an incorrectly
> specified transform.
> 
> Further, no it can't be automated.  The BOM and encoding 
> variables refer to
> the encoding of the XPath expression, not the transform input.
> </John>

OK, now I'm completely lost.  If the BOM and encoding aren't related to the
input stream, how could they be profitably used during parsing that stream?
I still don't understand enough about where unparseable UTF-16 would come
from.  Somehow the author knows the correct BOM and encoding but it is not
machine-discoverable in any way?

Could you provide a complete scenario?

> > 3) In my original design, I assumed that the output would be
> > automatically
> > serialized.  Then it occured to me that a similar argument to
> > that above
> > could be applied to say that perhaps some minor fix-up of the
> > output would
> > be needed and could be done using XPath's string functions.
> 
> Scenarios?  If the need for parse() is eliminated, is there 
> still a need for
> this?
> 
> <John>
> Symmetric doesn't mean equal.  parse() allows modification 
> *before* input.
> serialize() allows us to wrap changes around it, so we can 
> make changes
> *after* the output.
> </John>

Yes, you're right.  But examples of the kind of changes you want to allow
would help.  Arbitrary string manipulations on a serialized XML document
doesn't seem very robust.  XSLT provides a mechanism for structural
manipulations when filtering is not adequate.  It isn't clear that some kind
of minor fix-up cannot be handled declaratively.

Received on Wednesday, 15 March 2000 15:46:48 UTC