RE: Comments on last call draft

I don't see what's so hard about:

For obtaining byte order mark,

node *MyXMLProcessor(char *filename, char *BOM)
{
FILE *infile = fopen(filename, "r");
	fread(infile, 2, 1, BOM);
	fclose(infile);

	return YourXMLProcessor(filename);
}

For exact order, your implementation should simply throw an algorithm
unavailability exception if your lex-order-aware implementation encountered
an exact order signature.

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: Thursday, March 09, 2000 11:31 PM
To: IETF/W3C XML-DSig WG
Subject: Re: Comments on last call draft



> 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?

Yes when we use a DOM Level 2 implementation.

We can not sort attributes before XPath processing because DOM
has no reordering function.  So we have to sort after XPath
processing.

<root>
  <child b="b-value"/>
  <child a="a-value"/>
</root>

"//child/@*"

The result of applying the above XPath expression to the above
document is a node-set consisted of two attribute nodes (Attr in
DOM).  We can not decide whether we may sort the node-set
because Attr has no method returning its parent element and we
can not know whether these attribute nodes are in the same
element.  Attr in DOM Level 2 has the getParentElement() method.

> 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

We need not these information.

When an XML processor parses a signature document, all
characters including any XPath expression are represented in an
internal encoding, that is UTF-16 in DOM.  XPath evaluators in
Java, Xalan/LotusXSL and XT, receive expressions in UTF-16 and
they implements the XPath `string' instances as UTF-16 sequences.

> 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).

I do not know XML processors that provide the BOM information of
parsed document.  Some XML processors provide the encoding
information of the document entity with each original method but
it is very difficult or impossible in existing XML processors to
detect an encoding of specific node because XML documents may
contain external entities.

--
TAMURA Kent @ Tokyo Research Laboratory, IBM

Received on Friday, 10 March 2000 19:24:11 UTC