OpenSAML user discussion

["Scott Cantor" <>]

> I haven't looked at what your model is in awhile, so I'm not sure if
> they're really that different.  But one corollary to what I have said
> (it's the element that's nillable or not, not the type) is:  So at least
> in Java, literally *any* of our object provider impls could be used in a
> context that is nillable.  As long as the element on which the type is
> being expressed is declared nillable, then you have to be able to
> express the nil property.

I didn't realize you could do this on top of an xsi:type declaration. The
more this goes on, the more I'm convinced they completely botched this
concept.

> Examples (omitting namespace decls):
> 
> <saml:AttributeValue xsi:type="xs:string" xsi:nil="true" />
> 
> That would mean that our XSString provider needs to support the nil
> property.  Or else we need to have a separate NillableXSString that
> somehow gets built instead of the other one when appropriate, but like I
> said I don't see how that's feasible.

No, but I really didn't remember that was legal.

> So really, I think that any XMLObject, to the extent that it represents
> the content model of a type (and I argue they all do, really), needs to
> be able to express nil.  Assuming no multiple inheritance, mixins, etc.
> Maybe in C++ you could have a different solution, don't know.

No, if you can combine xsi:type with it, then I have to move it. The fact
that my element implementations can function for obscure cases as types
isn't really the issue, the problem is that the content model itself doesn't
control whether nil is possible.

-- Scott