OpenSAML user discussion

[Brent Putman <>]

Scott Cantor wrote:

>
> Best I can tell, anyType is not nillable, so I think in SAML it would 
only
> be the AttributeValue element that would get the flag.


Yeah, I don't think there's any way it can be, it's not applicable.  
Nillable is a property of an element, not a type.  xs:anyType is the 
ur-type, but a type nonetheless.



>
>
>
> It's a small change for me, so I'll take care of it. I can't say what the
> impact is in Java, I don't know what builder gets used by default for 
a bare
> AttributeValue.


In Java, with the default config, a bare AttributeValue would be an 
XSAny instance.

Having the relevant nillable type/element impls (see below) expose the 
nil property would work ok on the creation case, because you can control 
what you're building.  You could maybe have a Nillable interface or 
something that relevant impls could implement.  However, I don't think 
having the individual object impls expose the nil could work for the 
unmarshalling case, specifically for those that are an xs:anyType like 
AttributeValue.   You'd basically have to have nillable versions of any 
type you expected could be nillable (eg XSString vs. NillableXSString) 
and then unmarshall the right one looking at the type/element QName + 
xsi:nil presence.  I think that's totally untenable.

Unless Chad has a better idea, I think the only workable way is to in 
fact put in on XMLObject, with the other xsi attributes.  Of course, 
only those which are actually nillable could ever set it to true without 
causing schema violation, but we don't strictly prevent people from 
shooting themselves in the foot anyway.

So I'd propose:
1) put isNil/setNil on XMLObject, defaulting to false
2) marshaller only expresses it on the marshalled element if it's true
3) unmarshaller would unconditionally set it if it's present on the 
element, and hope that it is in fact valid for the element being 
unmarshalled.  Don't know what else you could do.  If schema compliance 
is really important, then I suppose you just have to schema validate 
when parsing.

If we want to be really anal and provide a safety net mechanism to 
prevent people from inadvertently doing the bad thing when creating 
objects, then we could also:
4) add an isNillable/setNillable to XMLObject, defaulting to false
5) implement setNil so that if isNillable is false, throws an illegal 
argument exception or something
6) actual defined elements/types (i.e. that are not anyType cases) which 
are nillable could just set to true in the constructor, etc
7) anyType cases like AttributeValue would just set to true externally, 
on construction, perhaps in the builder if a custom builder is used.


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.  But the nillable 
property is a  property declared on an element, not on a type.  If you 
have a FooType type and and element Foo that is declared to be of that 
type - it's the Foo element that would be nillable, not the FooType.  
But we don't really have anything that represents the element itself, 
only the type's content model (and a convenient default element name 
constant on the type).  So in that case we'd (presumably, if we don't 
put on XMLObject) just put it on the object impl (which really 
corresponds to the FooType) and hope that if someone uses FooType for 
another element that's not nillable, they don't set nil=true.


--Brent