RE: XSL WG comments on XML Signatures

I'm glad to see that the XSL experts are helping the XML
signature group to improve their use of XPath.

I'm adding a few comments below so that when XPath
filtering is rewritten, these issues can
be cleaned up at the same time.

At 12:44 00/03/15 -0800, Jonathan Marsh wrote:
> > -----Original Message-----
> > From: John Boyer [mailto:jboyer@PureEdge.com]

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

The i18n WG/IG was also rather lost on seeing $exprEncoding and $exprBOM.

The XPath engine of course has to know in which encoding the XPath
expression was in. But that's the XPath engine, not the XPath expression.
It would be extremely strange to include some switch in an XPath
expression saying something like
   If the XPath expression came in as Shift_JIS, then do A, else do B.
As for the BOM, the same arguments apply. In addition, the XPath
expression is element (or attribute?) content, so there is never
a BOM in front of it. To distinguish between BE and LE, just use
UTF-16-BE and UTF-16-LE if needed.


Regards,   Martin.



#-#-#  Martin J. Du"rst, I18N Activity Lead, World Wide Web Consortium
#-#-#  mailto:duerst@w3.org   http://www.w3.org/People/D%C3%BCrst

Received on Wednesday, 15 March 2000 22:21:28 UTC