OpenSAML user discussion

[Brent Putman <>]

Scott Cantor wrote:
>
> What I'm not doing correctly and may punt on is preserving 
xsi:nil="false"
> for cases that aren't nillable. That seems incredibly stupid to do, 
but it's
> legal, I assume (haven't tried it).


Actually, that's what I thought too, i.e. I thought it would always be 
legal (albeit redundant  and unnecessary) to explicitly express 
xsi:nil="false" on elements that aren't nillable.  But I tested earlier 
in Oxygen and it doesn't agree.  It only lets you express an xsi:nil 
(regardless of value) if the element is nillable, otherwise it throws as 
a schema violation.  If the element *is* nillable, then you can express 
either xsi:nil="true" or xsi:nil="false".  That's a little surprising, 
but I guess not totally so.  Oxygen uses Xerces btw.  Don't know if that 
behavior is correct vis-a-vis the spec or not, but that's what it does.



> One aspect of this that's a little pesky is that we kind of fudge the
> distinction between elements and types.   Without resurrecting the whole
> "are we type-oriented or element-oriented" discussion: with no
> exceptions that I can think of, our interfaces and impls really
> represent the content model defined by a type.

> Mine are not, and I think that's the difference. When I handle types, 
that's
> the weird/edge case. Everything else I have is element-based.


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.  And the only way to do that is to expose the 
nil property on everything, at least I think.  So that's another thing 
which argues for it being on XMLObject.

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.

<brentns:BrentAssertion xsi:type="saml:AssertionType" xsi:nil="true" />

Assumes I have a schema for brentns namespace where my element 
brentns:BrentAssertion is declared nillable.  There the Assertion 
provider needs to support the nil property.  (Not that that example 
necessarily makes semantic sense, but I think it and similar examples 
are legal and possible).

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.

--Brent