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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

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