We still need these simple types for validation otherwise references to simple types will fail. Seems to me we need to ask the WSDL working group whether these elements should show up in the component model and interchange format. From an implementation standpoint excluding these simple types will lead to inconsistency in the model as references to types that have been explicitly imported will be available while references to the XSD types, which are implicitly imported, will not be available. I think this is bad for Woden's consumability as it will require clients to handle built in schema types in a different way from the rest of their types.

Lawrence




"John Kaputin (gmail)" <[EMAIL PROTECTED]>

11/02/2006 07:19 AM

Please respond to
[email protected]

To
[email protected]
cc
Subject
Re: Does Woden still need to import XML Schema schema?





Jeremy,
at Dims request I've just opened JIRA WS-COMMONS-120. Details and patch are contained there. I think this is an oversight in XmlSchema, not something done on purpose. The equals(Object) method is overridden in XmlSchemaObject, which is a super class of XmlSchema. It would probably work OK if line no. and line position were implemented, but as these are always zero, the equals method returns true when it shouldn't, so I think further equality checking needs to be done in an XmlSchema.equals method. That's the basis of the JIRA.

In Woden, ComponentModelBuilder.buildElementsAndTypes contains the code:

       if(!fSchemasDone.contains(schemaDef)) {

where fSchemasDone is a List and schemaDef is an XmlSchema object. This indirectly invokes XmlSchema.equals which results in the problem reported in the JIRA.

John.

On 11/2/06, Jeremy Hughes <[EMAIL PROTECTED]> wrote:
On 11/2/06, John Kaputin <[EMAIL PROTECTED]> wrote:
>
> Lawrence or Arthur,
> Do we still need to import the schema for XML Schema into Woden to get the
> basic schema types into the model?
>
> I think this was done to satisfy the Part 1 spec Section 3.1 at [1] which
> says:
>
> "The built-in XML Schema datatypes are built-in to the WSDL 2.0 component
> model and are contained in the {type definitions} property of the
> Description component. "
>
> The other related history I can find is JIRA WODEN-1 and a mailing list
> thread at [2].
>
> Although the XML Schema schema is imported by Woden, its schema components
> don't appear to be used anywhere and they are not expected by the component
> interchange format when it checks for {element declarations} and {type
> definitions} in the Description component. Until now they have not appeared
> in the component model anyway due to a bug in the equals(Object) method of
> XmlSchema which is used indirectly by Woden's ComponentModelBuilder when it

what's the XmlSchema JIRA #?. Are you sure that's not done on purpose!?

> populates the {element declarations} and {type definitions} properties. I
> have a possible fix for XmlSchema (to fix Chameleon-4G for WODEN-13) but
> this means that all schema components inlined or imported within types
> element will now appear in {element declarations} and {type definitions},
> including those for the XML Schema schema.
>
> I can work around this in ComponentModelBuilder to exclude the XML Schema
> schema components from {element declarations} and {type definitions} so as
> not to break the component interchange tests, but in that case maybe I
> should just remove the Woden code that imports the XML Schema schema
> instead?
>
> I have run AllWodenTests with this code commented out and it does not break
> anything (except for some resolver tests whose asserts assume that XML
> Schema schema is present - easily changed).
>
>
> [1]
>
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#xsd-types
> [2]
http://lists.w3.org/Archives/Public/www-ws-desc/2006Jan/0038.html
>
>
> John Kaputin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
[EMAIL PROTECTED]
> For additional commands, e-mail:
[EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]


Reply via email to