- From: Ed Simon <ed.simon@entrust.com>
- Date: Mon, 14 May 2001 20:35:13 -0400
- To: w3c-ietf-xmldsig@w3.org
- Message-ID: <7D901CFF4FC51942AF52A0AD43AA3F821B61FC@sottmxs08.entrust.com>
1. The schema will not prevent people from having leading or trailing whitespace in the content of KeyName (and it shouldn't!). The spec will just say that any leading and trailing whitespace MUST be trimmed to obtain the actual KeyName. 2. The code will look something like this: Node nodeKeyName = XPathAPI.selectNode(doc, "//KeyName/text()"); // get the text content of <KeyName> String strNodeKeyName = nodeKeyName.nodeValue(); String strKeyName = strNodeKeyName.trim(); KeyResolver.resolveWithKeyName(strKeyName); Ed -----Original Message----- From: Joseph M. Reagle Jr. [mailto:reagle@w3.org] Sent: Monday, May 14, 2001 6:18 PM To: merlin Cc: Donald E. Eastlake 3rd; w3c-ietf-xmldsig@w3.org Subject: Re: KeyName white space I don't think I completely understand the problem yet. Is this to say that 1. the content model for KeyName should be precluded from having a white-space as the first or last character? (Not sure if this is possible using XML Schema patterns [1] since they don't support ^ and $.) 2. That a processor will not have those white spaces available to them? (What happens if people want to use generic xml tools like query or XPath where the whitespace is preserved/important) [1] http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#element-pattern At 22:18 5/14/2001 +0100, merlin wrote: >Agreed. DNames already have this property (from RFC 2253 I think), >and I believe so do base-64 coded data as well as integers, so >this would unify pretty much all of our text handling. > >merlin > >r/dee3@torque.pothole.com/2001.05.14/14:35:23 > >Hi, > > > >Some questions have arisen about in the XML Encryption activity the > >handling of white space in the content of the KeyName element. There > >was substantial feeling there that leading and trailing whitespace > >should be stripped from KeyName content. I think this would be an > >improvement but since it is in the XMLDSIG namespace, this list is > >the right place for discussion. What do others think? > > > >Thanks, > >Donald > >===================================================================== > > Donald E. Eastlake 3rd dee3@torque.pothole.com > > 155 Beaver Street +1 508-634-2066(h) > > Milford, MA 01757 USA +1 508-261-5434(w) > > > > >--------------------------------------------------------------------------- -- >Baltimore Technologies plc will not be liable for >direct, special, indirect >or consequential damages arising from alteration of the contents of this >message by a third party or as a result of any virus being passed on. > >In addition, certain Marketing collateral may be added from time to time to >promote Baltimore Technologies products, services, Global e-Security or >appearance at trade shows and conferences. > >This footnote confirms that this email message has been swept by >Baltimore MIMEsweeper for Content Security threats, including >computer viruses. > http://www.baltimore.com __ Joseph Reagle Jr. http://www.w3.org/People/Reagle/ W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature W3C XML Encryption Chair http://www.w3.org/Encryption/2001/
Received on Monday, 14 May 2001 20:35:45 UTC