- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Tue, 20 Mar 2001 19:06:33 -0500
- To: xmlschema-dev@w3.org
I recently returned to this question of extending a type that originally had a ANY as a permitted child (and the subsequent problems resulting from the ambiguous content model.) Hopefully, my new formulation [a] will enable a kind sole to point me in the right direction. (Attempts to have encryption redefine the meaning of the dsig namespace before importation seemed a bit complex, or more complex given this is something I'd like for other applications to easily do.) [a] http://www.w3.org/Encryption/2001/03/sigenc/#Option3 Forwarded Text ---- >Date: Tue, 20 Mar 2001 19:02:42 -0500 >To: "XML Encryption WG " <xml-encryption@w3.org> >From: "Joseph M. Reagle Jr." <reagle@w3.org> >Subject: XENC use of ds:KeyInfo >Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org> > >I've posted a small analysis [1] of the options we have with respect to >reusing ds:KeyInfo. In the end, the XML Encryption WG could go the easy >route and opt for option 1/2. However, I personally think this is slightly >unfortunate and I think the dsig spec/schema should permit extensions as >shown in option 3, but I'm not quite sure how to do it given dsig's use of >ANY. > >All thoughts are welcome. > >http://www.w3.org/Encryption/2001/03/sigenc/ End Forwarded Text ---- __ 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 Tuesday, 20 March 2001 19:06:35 UTC