On Wed, Feb 25, 2009 at 8:02 PM, Dan Becker <[email protected]> wrote:
> I am working on http://issues.apache.org/jira/browse/TUSCANY-2856, and I > notice a discrepancy in the way XML contributions are validated. This > particular problem shows up validating JMS binding XML elements, but I > imagine it might show up elsewhere as well. > > In binding-jms JMSBindingProcessorTestCase we read JMS binding header > elements with properties with no validation issues. For example, this type > of input is accepted by JMSBindingProcessorTest: > <binding.jms uri=\"jms:testQueue\" > > <headers> > <property name="p1">bla</property> > </headers> > </binding.jms> > > On the other hand, itest-jms PolicyHeadersTestCase attempts to read this > input, and runs into validation errors: > <binding.jms uri="jms:ServiceQueue"> > <headers JMSType="myType" JMSCorrelationID="xyz" > JMSDeliveryMode="PERSISTENT" JMSTimeToLive="4321" JMSPriority="7"> > <property name="headP1">myHeadP1</property> > </headers> > </binding.jms> > > The error comes from the ValidatingXMLStreamReader complaining about the > name attribute on the property element, which technically is not legal > according to the sca-binding-jms.xsd: > Feb 25, 2009 8:26:37 AM > org.apache.tuscany.sca.contribution.processor.ValidatingXMLStreamReader > SEVERE: XMLSchema validation error occured in: null ,line = 25, column = > 19, Message = cvc-type.3.1.1: Element 'property' is a simple type, so it > cannot have attributes, excepting those whose namespace name is identical to > 'http://www.w3.org/2001/XMLSchema-instance' and whose [local name] is one > of 'type', 'nil', 'schemaLocation' or 'noNamespaceSchemaLocation'. However, > the attribute, 'name' was found. > > 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? > > -- > Thanks, Dan Becker Hi Dan Two things here. 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. The validating schema factory is retrieved by the composite document processor IIRC so this will show a different effect to those tests that don't use a validating schema processor. Regards Simon
