Re: xmlspy: does ##other apply to only subsequent target ns

At 23:21 2/19/2001 +0000, Henry S. Thompson wrote:
>Presuming the content model for ds:KeyInfoType is still something like
>
>   <xs:choice maxOccurs="unbounded">
>    . ..
>    <xs:any namespace="##other"/>
>   </xs:choice>

Yep [1].

[1] http://policy.w3.org/sigenc/xmldsig-core-schema.xsd

>You have two problems:
>
>1) the minOccurs on the choice defaults to 1, so your
>keyRetrievalMethod is being validated by the choice's required first
>iteration, as it were;
>2) your content model is ambiguous -- if there were _two_
>keyRetrievalMethod elements, the second could stay with the <any> or
>go with the added explicit <element>.

But they are from different namespaces...?

>Isn't what you want to _restrict_ KeyInfoType with the
>KeyRetrievalMethod reference?  This should have the right result.

Actually yes, but I haven't figured out how to restrict a referenced part of 
KeyInfoType. Is it possible to say an element is of ds:KeyInfoType except 
for a restriction in one of the things it references: ds:RetrievalMethod? In 
this instance, I'm trying to create a enc:KeyInfo of dsig:KeyInfoType but 
restrict the ds:RetrievalMethod's Type attribute (via fixing or removing the 
attribute value since the Type will always be a EncryptedKey -- we don't 
need/want generality where it is wanted in dsig).

In general, I have three possible strategies, and I'm not sure what the best 
practice is.

(I'm renaming the restricted RetrievalMethod to enc:KeyRetrievalMethod for 
clarity, but it's not necessary, and be a cool demonstration of polymorphism 
if I find and a solution and don't rename it).

A. Create a new but orphaned (in the encryption namespace) 
enc:KeyRetrivalMethod that is permitted by ds:KeyInfoType's ANY:
   <enc:EncryptedData>
     <ds:KeyInfoType>
       <enc:KeyRetrievalMethod>
     </..>

This has a weird hodgepodge/striping and isn't the tightest object design 
(ANY can be useful, but discouraged where you can do real OO IMHO.)

B. Create a enc:KeyInfoType and <enc:KeyInfo> element that is derived from 
ds:KeyInfoType with a restricted ds:RetrievalMethod, or failing that a new 
enc:KeyRetrievalMethod.

In the instance, it looks like everything is from enc: but if you have the 
schema you understand the relationships.

C. Create a completely new enc:KeyInfoType that is defined the same as 
ds:KeyInfoType except for this definition.

This looks like B, but loosing the OO complexType relationships.


__
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 February 2001 13:38:18 UTC