Thanks for the clarification and I guess your explanation answers the original question in this thread.
You asked: "Do you need it at parse time? "
Well, I guess we need it as an extension attribute and nothing more. So, it would be okay have the same treatment for it as any other extension attribute.
As you suggested we could implement getXsiSchemaLocation() from DescriptionElement and leave it upto the client app to decide what to do with the schema representation. (I was initially of the opinion that Woden should take care of the schema too.)
Thanks,
Oshani.
On 9/13/06, Arthur Ryman <
[EMAIL PROTECTED]
> wrote:
Oshani,
I mean that it should NOT be treated as a WSDL extension. It should be a well-typed part of the interface, e.g. on the DocumentElement, maybe getXsiSchemaLocation() and return an array of URIs. However, it depends on what you want to do with it. Do you need it at parse time?
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: [EMAIL PROTECTED]
"Oshani Seneviratne" <[EMAIL PROTECTED]> 09/12/2006 02:41 PM
[EMAIL PROTECTED]
Arthur Ryman/Toronto/[EMAIL PROTECTED] [email protected], [EMAIL PROTECTED] Re: [WODEN-USER :)] how to access xsi:schemaLocation attribute of <description> from either parser?
Hi Arthur,
I am trying to figure out how to implement this with OM. So, could you please explain what you meant by "handled as built-in"? Is it having another XMLAttr impl, or another representation of schema in woden (similar to inline/imported schema)?
Thanks,
Oshani
On 9/12/06, Arthur Ryman <[EMAIL PROTECTED] > wrote:
I think the xsi attributes shown be handled as built-in since they are part of XSD. The extension mechanism should be reserved for WSDL extensions.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: [EMAIL PROTECTED]
"Jeremy Hughes" <[EMAIL PROTECTED] >
Sent by: [EMAIL PROTECTED]09/12/2006 04:57 AM
[email protected]
[email protected] , [EMAIL PROTECTED] Re: [WODEN-USER :)] how to access xsi:schemaLocation attribute of <description> from either parser?
I think this should be handled like any other extension. Anything not
in the WSDL namespace is an extension to the WSDL. If we start
'special-casing' extensions then we could find other extensions would
like to do the same.
Jeremy
On 9/12/06, Oshani Seneviratne <[EMAIL PROTECTED] > wrote:
> Hi Graham and all,
>
> Even in the DOMWSDLReader, I assume that parseExtensionAttributes
> method was not intended to handle this. I'm referring to the comment
> "//TODO handle xsi attrs elsewhere, without need to register". (Please
> correct me if I'm wrong on this! )
>
> So, theoretically as you asked, how about having a method like
> parseExtensionAttributeSchema (or whatever the name) which gets called
> from the parseExtensionAttributes? We could also have a schema
> implementation like ExtensionAttributeSchema that could represent such
> external schemas. (Or maybe ImportedSchema could be used here).
> Any comments?
>
> Also, just to clarify, in the WSDL fragment you've given there are 2
> schema locations for 1 attribute. Is that possible?
>
> > <description targetNamespace="http://example.com/bank "
> > xmlns="http://www.w3.org/2006/01/wsdl "
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "
> > xsi:schemaLocation=
> > "http://www.w3.org/2006/01/wsdl
> > http://www.w3.org/2006/01/wsdl/wsdl20.xsd
> > http://www.w3.org/2001/XMLSchema
> > http://www.w3.org/2001/XMLSchema.xsd " >
> >
>
> Thanks and Regards,
> Oshani
>
> ---------------------------------------------------------------------
> 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]
