RE: Comments on last call draft

Hello all,

I have long suspected that once someone actually tried the XSLT transform,
they would indeed find that it has the attribute order problem.  Thanks for
trying it.  As I don't really like that transform, I'm disinclined to
suggest fixes, so perhaps someone else could give it a try.

As for exact order in the XPath transform, are you saying that if we
eliminated exact order and used only lex order, then we could accomplish the
XPath transform with some set of existing tools?  If so, then I would not
object to using only lex order.  Furthermore, I would find it very hard to
believe that lex order could not be accomplished with existing tools since
one only needs to   sort the attributes, and it's not like we don't know how
to sort.

As for exprEncoding and exprBOM, you should note that you will be receiving
an XML document containing a signature element which contains the XPath
expression, the encoding of that document determines the encoding of the
XPath expression.  I created exprEncoding and exprBOM as a way of making it
clear that the application must provide these pieces of information from the
document to the XPath transform precisely so that the expression could be
reencoded to a format that is suitable for your XPath expression evaluator
(or the application could throw an exception if it cannot perform the
conversion).  Either way, the XPath transform needs to know the XML document
encoding of the XPath expression string in order to decide whether or not it
can process and/or reencode the expression.

As for re-using existing XML processors and XPath libraries, I'm quite
certain you are incorrect about not being able to use an existing XML
processor (Clark's parser, for example, can easily be used to create the
parse tree I've specified).  As well, I'm quite certain that XPath has not
been around long enough to draw the type of conclusion you are drawing.  In
particular, we must be careful not to take reusability too far.  The XPath
recommendation permits the DSig application to do everything I have
specified.  These needs are in excess of previous applications in some
places, so of course we cannot completely reuse those libraries.  But the
fact that XPath has not been fully exploited in the past few months in which
it has been a recommendation does not mean we should "give up".

John Boyer
Software Development Manager
PureEdge Solutions, Inc. (formerly UWI.Com)
jboyer@PureEdge.com





-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of TAMURA Kent
Sent: Wednesday, March 08, 2000 6:44 PM
To: IETF/W3C XML-DSig WG
Subject: Comments on last call draft



6.6.3 XPath Filtering:

I would give up implementing XPath filtering based on the draft.

Don't use information not in the XML Information Set [1], such
as $exprEncoding, $exprBOM, and Exact Order, and don't suppose
strings in XPath can have each character encoding.  We could not
use existing XML processors and existing XPath engines to use
these information.

I think representing digital signatures in XML would be nonsense
if we could not reuse general-purpose XML libraries.


6.6.4 XSLT Transform:

The XSLT transfrom has the same problem as the XPath filtering
about attribute order.


7.1 XML 1.0, Syntax Constraints, and Canonicalization:

The sixth item in the first list, "6. for elements declared ..."
is incorrect.  XML processors must not remove any white space.


7.2 DOM/SAX Processing and Canonicalization

The first paragraph:
> losing the namespace prefixes in the source text and, in most
> cases, losing where namespace declarations appeared in the
> original instance.

Applications can know the namespace prefixes and the namespace
declarations with SAX 1.0, DOM Level 1 and Level 2.


[1] http://www.w3.org/TR/xml-infoset

--
TAMURA Kent @ Tokyo Research Laboratory, IBM

Received on Thursday, 9 March 2000 12:42:03 UTC