[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] ISSUE 76: binding.ws schema uses ##any insteadof ##other - proposal
David Booz wrote: > Hi Folks, > > Here's a proposal for ISSUE 76 [1] ready for review today. It's called > v4 because it has iterated inside IBM, but this is the first document > based proposal that the TC has seen. > /(See attached file: sca-binding-ws-1.1-spec-cd02-rev3_issue76v4.doc)/ > > > As part of making the changes for this issue, I did some "testing", ok, > playing with the schemas and Eclipse 3.4 to ensure that the schemas are > working as we expect. The schema tests are based on the CD03 Assembly > schemas in the OASIS SVN repository. I had to modify them for these > tests, but I have not committed the modifications to SVN. The changes > are just in my eclipse workspace. > > (1) To address the questions of schema extensibility, I think the > binding ws schema should look like this (which is what's in the > proposal). I removed the <anyAttribute>, removed the <wireFormat> and > <operationSelector> and fixed the EndpointReferenceType. > /(See attached file: sca-binding-ws-1.1-cd02.xsd)/ +1 > (a) /(See attached file: test1.xml)/- verifies that attribute and > element extensibility work as I think they should. Eclipse reports no > errors. If one were to modify the binding ws schema to remove the <any>, > this xml file will become invalid. Also, note that attribute > extensibility works without the anyAttribute in the binding ws schema. > > (b)/(See attached file: test2.xml)/ - verifies that out of place element > extensions are flagged as an error. <other:fred/> is in error. > > (c)/(See attached file: test3.xml)/- verifies that attributes without > namespace qualification are treated as part of the SCA namespace and > flagged as an error. @ubi is in error. > Nit: such attributes are not part of the SCA namespace, they are "local" or attributes with no NS. Unlike elements, attribute do not use the default NS binding. > (d) /(See attached file: test4.xml)/- This is the most interesting test. > I updated the base assembly schema to make the wireFormat element abstract. > <!-- WireFormat Type --> > <element name=/"wireFormat"/ type=/"sca:WireFormatType"/ abstract=/"true"//> > <complexType name=/"WireFormatType"/ abstract=/"true"/> > <sequence> > <any namespace=/"##other"/ processContents=/"lax"/ minOccurs=/"0"/ > maxOccurs=/"unbounded"/ /> > </sequence> > <anyAttribute namespace=/"##other"/ processContents=/"lax"//> > </complexType> > Eclipse did NOT flag the <wireFormat/> element in error as presumed by > the previous TC discussion. I can't make heads or tails out of the > schema spec, maybe one of you can explain this? > I *think* this is a bug in Eclipse. The XML Schema primer [.1] Section 4.7 says: "XML Schema provides a mechanism to force substitution for a particular element or type. When an element or type is declared to be "abstract", it cannot be used in an instance document. When an element is declared to be abstract, a member of that element's substitution group must appear in the instance document. When an element's corresponding type definition is declared as abstract, all instances of that element must use xsi:type to indicate a derived type that is not abstract. " XML Schema part 1, Section 3.3.4 [.2] has this rule as part of the validation rules: "2 Its {abstract} must be false." But, I always learn something new, everytime I look at the XML Schema spec for something specific. -Anish -- [.1] http://www.w3.org/TR/xmlschema-0/#abstract [.2] http://www.w3.org/TR/xmlschema-1/#cElement_Declarations > > [1] http://www.osoa.org/jira/browse/BINDINGS-76 > > Dave Booz > STSM, BPM and SCA Architecture > Co-Chair OASIS SCA-Policy TC and SCA-J TC > "Distributed objects first, then world hunger" > Poughkeepsie, NY (845)-435-6093 or 8-295-6093 > e-mail:booz@us.ibm.com > > > ------------------------------------------------------------------------ > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]