OpenSAML user discussion

[Brent Putman <>]

Neill Miller wrote:
>
> What I (think I) want though is something like this:
>
> <saml:Attribute Name="MyAttribute" NameFormat="myType">
>  <saml:AttributeValue xmlns:myns="http://www.myns.org"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xsi:type="myns:myType">
>   <myns:myType param1="foo" param2="bar"/>
>  </saml:AttributeValue>
> </saml:Attribute>
> --------------------
>   

Without the xsi:type, but yes, that looks correct for what you have
described.

> I can get (very) close to the latter output by building that XML string in 
> the marshallElementContent method (and commenting out my marshallAttributes 
> method) of my marshaller, and adding it to the domElement there, but the 
> brackets get escaped in that case:
>
> <saml:Attribute Name="MyAttribute" NameFormat="myType">
>  <saml:AttributeValue xmlns:myns="http://www.myns.org"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xsi:type="myns:myType">
>    &lt;myns:myType param1="foo" param2="bar"/&gt;
>  </saml:AttributeValue>
> </saml:Attribute>
>   


> That's likely because of the way the XMLHelper.appendTextContent is 
> working.  Is there another method I can use that won't cause the escaping, 
> or is there a better XML output format I should be working toward to get 
> this going?
>   

Yes, your problem is that you are treating the child elements of your
custom type as text, and not as child elements.

The most straightforward approach and path of least resistance is that
you should implement XMLObject providers for all your elements,
including for example the <myns:myType> child that you have above. 


The other possible approach - though I wouldn't necessarily strongly
recommend it because there's no compelling reason to do it this way - is
in your marshaller and unmarshaller for the custom type, implement what
you need vis-a-vis the DOM directly, e.g. in the marshaller by appending
a DOM Element Node to your custom type parent Element.

The latter probably requires more advanced understanding of the library,
and doesn't offer any advantages in this case over the former, so I'd
recommend just implementing XMLObjects for any needed custom elements.

>  Are there any examples that aren't the XS* types included in the library?
>   

For my first suggestion - yeah, that's pretty much what all the
XMLObject providers in the entire OpenSAML stack do.

For the second - the only place where we currently do this is in the
handling of the ds:Signature element in the java-xmltooling library.  It
has to be handled in a different manner because a different underlying
library (Apache XML Security) handles much of the DOM handling.  It's an
example of how that might be done.

--Brent