- From: John Boyer <JBoyer@PureEdge.com>
- Date: Thu, 12 Jul 2001 09:48:00 -0700
- To: <vdv@dyomedea.com>, "merlin" <merlin@baltimore.ie>
- Cc: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>, <w3c-ietf-xmldsig@w3.org>, <lde008@dma.isg.mot.com>
Hi Eric, Could you explain a bit more clearly what you mean by "specify which namespaces prefixes cannot be rewritten"? An example to show the behavior you would expect of such a feature would be helpful. It is difficult to tell without more information why the regular XML c14n does work in the following: "If I wanted to canonicalize a XSLT template or a W3C XML Schema element definition I would certainly like to preserve all the prefixes." Thanks, John Boyer Senior Product Architect, Software Development Internet Commerce System (ICS) Team PureEdge Solutions Inc. Trusted Digital Relationships v: 250-708-8047 f: 250-708-8010 1-888-517-2675 http://www.PureEdge.com <http://www.pureedge.com/> -----Original Message----- From: Eric van der Vlist [mailto:vdv@dyomedea.com] Sent: Thursday, July 12, 2001 6:37 AM To: merlin Cc: Donald E. Eastlake 3rd; w3c-ietf-xmldsig@w3.org; lde008@dma.isg.mot.com Subject: Re: initial Exclusive Canonicalization draft merlin wrote: > > Hi Eric, > > r/vdv@dyomedea.com/2001.07.12/13:59:31 > >I find the idea of UnsuppressedNamespacePrefixList [1] very interesting > >and I wonder if a "DoNotRewriteNamespacePrefixList" that would specify > >which namespaces prefixes cannot be rewritten (or a > >"MayBeRewrittenNamespacePrefixList" that would specify which of them can > >be rewritten) couldn't solve the issue of prefix rewriting in a very > >consensual way. > > Does rewriting anything other than all prefixes actually provide > any benefit? > > I understand that normalizing namespace prefixes may be useful to > applications that do not preserve this information. However, if > we are not to normalize certain prefixes then that implies that > the relevant application will also preserve those prefixes, which > implies that it could preserve all prefixes? > > I presume that you have a use in mind; can you elaborate? I was proposing this by analogy with UnsuppressedNamespacePrefixList... If I wanted to canonicalize a XSLT template or a W3C XML Schema element definition I would certainly like to preserve all the prefixes. A common class of applications that will likely be using QNames are all the applications using XPointer expressions. The latest XPointer LC offers a way to define the namespaces within the XPointer expression itself [1], though and these applications should now be able to deal with NS prefixes rewriting. I am not a great supporter of using QNames as values and I was more concerned by finding a way to (optionally) include prefix rewriting in the canonicalization method than by the granularity of the feature and, you're right, a boolean parameter (RewritePrefixes or DontRewritePrefixes) may be a better way to achieve it. [1] http://www.w3.org/TR/2001/WD-xptr-20010108/#ns-context Eric > Merlin > > ------------------------------------------------------------------------ ----- > 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 -- See you at XTech in San Diego. http://conferences.oreillynet.com/cs/os2001/view/e_spkr/790 ------------------------------------------------------------------------ Eric van der Vlist http://xmlfr.org http://dyomedea.com http://xsltunit.org http://4xt.org http://examplotron.org ------------------------------------------------------------------------
Received on Thursday, 12 July 2001 12:48:32 UTC