[xsd-users] ##any type problems

[Bradley Beddoes]

Hello Boris,

Boris Kolpackov wrote:
> Hi Bradley,
> 
> Bradley Beddoes <beddoes at intient.com> writes:
> 
>> Yes thats exactly how it is intended to be used here in the SAML schema,
>> ArtifactResponse the element having problems may contain any message
>> from the SAML protocol when it is being transmitted
> 
> Can it contain any of the elements from StatusResponseType (from
> which ArtifactResponseType inherits): Issuer, Signature, Extensions,
> or Status? If the wildcard is supposed to carry payload then I think
> it is unlikely to contain these "header" elements. If that's the
> case then you could ignore the error (with an appropriate command
> line option that I can add).
> 

Yes you've got it 100% correct there, those elements should not be 
directly represented as the any element although assuming a fuller SAML 
message was embedded here they may appear at some lower level in the 
structure ie:
<StatusResponse>
  <Issuer>
  ...
  <Request> <-- substitute for any type
	....
	<Issuer/>
	....
  </Request>
</StatusResponse>

 From the way your explaining how the validator is working and the XSD 
code which I looked into today I assume (with lets face it little real 
world knowledge of the working of XSD) this wouldn't pose an immediate 
problem, the switch to disable the failure may be a decent option here 
for testing at least, in the short term I don't intend to be using the 
ArtifactResponseType anyway so simply getting the rest of the bindings 
generated successfully is much more important. Longer term we will be 
implementing logic to support that part of the standard. Providing that 
switch would be much appreciated.

> 
>> What sort of work would be required to support this?
> 
> There are two ways to support ##any in general case that I can think
> of at the moment:
> 
> 1. Implement full-blown structure validation. This is a lot of work
>    and also has other negative consequences such as significantly
>    increasing object code size. At the moment we are working on a
>    hybrid Parser/Tree mapping which will support validation in the
>    generated code.
> 
> 
> 2. Use Xerces-C++ post-schema validation infoset (PSVI) to figure
>    out associations. This shouldn't be too hard to implement and
>    probably won't increase the generated code by too much. The only
>    significant limitation of this approach is that it will only
>    work with validation enabled.

I personally don't see that as a negative thing in this case anyway or 
other such cases with complex schemas such as this, surely those with 
the need to use ##any also have the need to make sure the XML they are 
processing is valid. This would probably be my preferred option going 
forward given that we are already seeing some 17k LOC generated for 
saml-schema-metadata-2.0.xsd for example

regards,
Bradley

> 
> 
> hth,
> -boris