- From: Henry S. Thompson <ht@cogsci.ed.ac.uk>
- Date: 21 Feb 2001 15:47:57 +0000
- To: "Joseph M. Reagle Jr." <reagle@w3.org>
- Cc: xmlschema-dev@w3.org
"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