OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xacml-users] Schema to Java binding

Yes, it's a problem and I had to struggle with it in both Java (xml beans) and in Ruby. The code looked ugly in Java and in Ruby I've ended up with manual parsing and no binding at all. The other problem that you might face: memory consumption when you serialize XML with millions of nodes to Java classes. I believe some popular PDP implementations don't even do schema validation, which is dangerous in my view. XSD is unnecessary complicated in XACML and could/should be simplified. On the other hand, the engine that don't do schema validation should be considered as non-compliant with the spec.


From: Nick Duan <nduan@verizon.net>
To: xacml-users@lists.oasis-open.org
Sent: Fri, July 1, 2011 9:11:24 AM
Subject: [xacml-users] Schema to Java binding

Has anyone had any problems with XACML to Java data binding?  The complexity of the schema and the combination of them (with SAML, XML digital signature, XML encryption) really make the data binding very complicated.  For instance, the schema is using substitutionGroup quite extensively, and it was a nightmare to bind an element with an substitutionGroup to Java, especially when those types are defined in abstract.  The JAXB spec states that the element with substitutionGroup in the schema have to be mapped explicitly (e.g. via custom binding).  Another problem is that the xacml-context:AttributeValueType is define with xsd:any.   This is just a wildcard that no binding framework can deal by default and has to be defined via some custom binding.  If everyone is creating his/her own custom binding, there won’t be any assurance of interoperability.


I’d like to learn from the schema authors on any suggestions of how to deal with the binding issues.  Is this the intension that more concrete elements/types be defined in some derived schemas within some profile standards? 


Any comments/suggestions are highly appreciated.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]