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

"Joseph M. Reagle Jr." <reagle@w3.org> writes:

> 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...?

Sorry, I thought they were in the same namespace.

> >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.

Only possible if they are the same element, you can change the type,
see misunderstanding above.

 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).

Sure, you can do that:  all you have to do, since RetrievalMethodType
is not used anywhere else, is just redefine it to not have the Type
attribute.  This has to be done in a stub document which is in the
dsig namespace.

> 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.)

Yes, I think that would work.

> 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.

Note that in order to make that work you'd have to declare each new
element in enc: to be in the substitution group of the corresponding
element in ds:.

> 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.

This would not require the substitutionGroup stuff.

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

Received on Wednesday, 21 February 2001 10:48:05 UTC