[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]