Simon Laws wrote:
On Wed, Feb 25, 2009 at 8:02 PM, Dan Becker <[email protected]> wrote:
I notice that JMSBindingProcessorTestCase sets up its own
ExtensibleStAXArtifactProcessor. PolicyHeadersTestCase uses
SCADomain.newInstance to create a NodeImpl which sets up a
StAXArtifactProcessor.
Can anyone point me in a direction as to which StAX processor set up method
is correct or other insight as to how to validate these composites properly?
Firstly the schema we currently have in 1.x doesn't specify that a name
attribute can appear in this place so the error is correctly being reported.
However what I didn't notice when I reported the problem in the first place
is that the OSOA spec is internally inconsistent in that the psuedo schema
shows that the name attribute is intended to the allowable but the actual
schema at the back of the spec doesn't include it. I think we need to fix
the schema we have on the assumption that this is just an editorial error in
the spec. The OASIS spec goes this way anyhow so it would seem to be taking
us in the right direction.
Thanks Simon. I hear what you are saying, and it makes sense that we
should allow the more complex property elements with name and type
attributes. I'll update the schema for TUSCANY-2856.
Additionally, the Tuscany JMSBindingProcessor is already set up to read
the complex binding properties with name and type attributes. So even
though the older schema disallows it, the read and write code already
processes it.
--
Thanks, Dan Becker
