Closing on Whitespace and Examples 3.4 and 3.7

During the conversation [1] Kevin Regan and Tamura Kent argued for a change 
to the spec; Merlin Hughes, John Boyer, and Donald Eastlake argued not to 
change. So just given the numbers, I'd recognize that's not consensus to 
change the spec and momentum carries the day. The substantive result is that 
we need to ensure non-validating parsers (including Xerces) do the right 
thing with respect to white-space. Merlin has suggested a patch but received 
no feedback. Could other implementors also send in a comment? Are there 
other parsers we need to identify and ensure work the right way?

[1] My confused little summary of the discussion is below: <smile>

Kevin noted that such white space might be altered in processing or
transport and why is it considered a substantive variance under
canonical equivalence? John responded that we do this for
interoperability with non-validating parsers. The XML specification says
ALL processors must be capable of providing this information and validating 
parsers must provide information as to whether it was
significant. Applications that want to minimize white space could do it
themselves prior to signing. If this isn't the case, when used with
validating processor, the DTD can be tweaked. When used with a
non-validating parser it should do the right thing -- as that's why we
went down this path in the first place and unfortunately, as Kent noted,
that Xerces-J's DOM does not do this (so examples 3.4 and 3.7 throw
errors). Don argued this fact should not force us to require validating
processors. Instead, as John pointed out, we should get the
non-validating parsers to do the right thing. Merlin said he's gotten
Xerces to work right with a simple patch but they've been unresponsive.

__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Wednesday, 22 November 2000 11:17:33 UTC