Home » Archived » XML Schema Definition (XSD) » Suitability of XSD for particular task
| Suitability of XSD for particular task [message #57698] |
Mon, 14 February 2005 22:03  |
 Bruno Wassermann
Messages: 21
Registered: July 2009 |
Junior Member |
|
|
Greetings XSD'ers.
I have started experimenting with XSD enthusiastically a few days ago,
being convinced that it was the right tool for the task I would like to
outline. A few days later (today) I am not so sure anymore. Before
forgetting about XSD and implementing the below task 'by hand' (querying
DOMs directly), please take a look at what I am trying to achieve and be
so kind to share your thoughts with me as to the suitability of XSD for
this.
THE TASK
(+) We want to parse WSDL files and specifically (surprise) query the XML
Schemas which may be defined in the <wsdl:types> section. [Given that XSD
imports are present in the files, xSD does a great job here.]
(+) From this data, we want to generate a model that is to be displayed in
a tree viewer. We will display a set of <message>s (parsed by a separate
piece of code). Expanding these nodes, we want to display any XSD types
referenced from within the <message> and in turn the types defining these
types. We need a way of differentiating between complex and any of the XSD
simple types.
(+) Furthermore, a type X may reference an element or a type Y in another
(imported) schema. In the tree viewer we want these types (Y, Z, etc.) to
appear as children of X.
(+) Alternatively, a type X may have a complex type definition which
contains an element whose type definition specifies a type in a separate
schema.
I cannot see a straightforward way to achieve; at least XSD doesn't seem
to buy me that much in comparion to generating DOMs of the involved
schemas and turning this information into the desired model
representation.
Please share your wisdom and let me know what you think. Can you see how
to achieve this task with XSD having a serious advantage over a
custom-built piece of code. Let me know if this needs any further
clarification.
Many thanks,
-- Bruno
|
|
|
| Re: Suitability of XSD for particular task [message #57722 is a reply to message #57698] |
Tue, 15 February 2005 11:28  |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Bruno,
It sounds like XSD will help significantly by loading imported and
included schemas properly and automatically, by providing name lookup to
find the things you are searching for, and by providing a structured
model for analyzing complex content. I would imagine that you would use
XSD to load the .wsdl giving you access to all the embedded schemas in
the resource's getContents as well as access to any imported or included
schema via additional resources in the resource set. Given these, and a
type name/namespace you want to lookup, you'd iterate over the schemas
in the wsdl resource and do resolveTypeDefinition(namespace, name) until
one returns an XSDTypeDefinition with a non-null getSchema, i.e., one
that's properly resolved rather than an unattached placeholder. You'd
be able to check instanceof
XSDComplexTypeDefinition/XSDSimpleTypeDefinition. For a complex type,
you could walk its particles and its attribute uses to determine what
other types it references.
If you don't use XSD, you'll need to do an awful lot yourself. It's not
so easy to figure out which schemas to import or include (or to handle
the circularity in these) nor is it so easy to resolve names which
you'll need to do for all kinds of things such as dealing with things
like elements reference, attribute references, model group definition
references, base types, and so on. I would expect that doing this with
custom code would only be feasible if you can make many simplifying
assumptions about the complexity of the schemas you will need to handle.
Bruno Wassermann wrote:
> Greetings XSD'ers.
>
> I have started experimenting with XSD enthusiastically a few days ago,
> being convinced that it was the right tool for the task I would like
> to outline. A few days later (today) I am not so sure anymore. Before
> forgetting about XSD and implementing the below task 'by hand'
> (querying DOMs directly), please take a look at what I am trying to
> achieve and be so kind to share your thoughts with me as to the
> suitability of XSD for this.
>
> THE TASK
> (+) We want to parse WSDL files and specifically (surprise) query the
> XML Schemas which may be defined in the <wsdl:types> section. [Given
> that XSD imports are present in the files, xSD does a great job here.]
>
> (+) From this data, we want to generate a model that is to be
> displayed in a tree viewer. We will display a set of <message>s
> (parsed by a separate piece of code). Expanding these nodes, we want
> to display any XSD types referenced from within the <message> and in
> turn the types defining these types. We need a way of differentiating
> between complex and any of the XSD simple types.
> (+) Furthermore, a type X may reference an element or a type Y in
> another (imported) schema. In the tree viewer we want these types (Y,
> Z, etc.) to appear as children of X.
> (+) Alternatively, a type X may have a complex type definition which
> contains an element whose type definition specifies a type in a
> separate schema.
> I cannot see a straightforward way to achieve; at least XSD doesn't
> seem to buy me that much in comparion to generating DOMs of the
> involved schemas and turning this information into the desired model
> representation.
> Please share your wisdom and let me know what you think. Can you see
> how to achieve this task with XSD having a serious advantage over a
> custom-built piece of code. Let me know if this needs any further
> clarification.
>
> Many thanks,
>
> -- Bruno
>
>
>
|
|
|
| Re: Suitability of XSD for particular task [message #57747 is a reply to message #57722] |
Tue, 15 February 2005 17:28 |
Bruno Wassermann
Messages: 21
Registered: July 2009 |
Junior Member |
|
|
Thank you for your reply, Ed.
As I said before, I agree that XSD is doing a great job wrt loading schemas
and resolving imports. It is the transformation of the model XSD provides
you with into a 'more semantic' model of the schemas based on certain
requirements (i.e. hide some information from the user - if you don't just
want to display a tree representation of whatever has been parsed (cf.
XSDEditor)). But I think that is a difficulty introduced by the application
itself rather than the XSD API :-(
Out of interest, how do you think XSD compares to Sun's XSOM? Have you
looked at XSOM (https://xsom.dev.java.net/). Looks like XSD provides a bit
more functionality (e.g. resolve references / types, load schemas from WSDL
files). It would be interesting to know which implementation has a larger
user group and whether or not the use cases for which these two
implementations are used are the same or not.
Regards,
-- Bruno
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:cusmbt$cqq$1@www.eclipse.org...
> Bruno,
>
> It sounds like XSD will help significantly by loading imported and
> included schemas properly and automatically, by providing name lookup to
> find the things you are searching for, and by providing a structured
> model for analyzing complex content. I would imagine that you would use
> XSD to load the .wsdl giving you access to all the embedded schemas in
> the resource's getContents as well as access to any imported or included
> schema via additional resources in the resource set. Given these, and a
> type name/namespace you want to lookup, you'd iterate over the schemas
> in the wsdl resource and do resolveTypeDefinition(namespace, name) until
> one returns an XSDTypeDefinition with a non-null getSchema, i.e., one
> that's properly resolved rather than an unattached placeholder. You'd
> be able to check instanceof
> XSDComplexTypeDefinition/XSDSimpleTypeDefinition. For a complex type,
> you could walk its particles and its attribute uses to determine what
> other types it references.
>
> If you don't use XSD, you'll need to do an awful lot yourself. It's not
> so easy to figure out which schemas to import or include (or to handle
> the circularity in these) nor is it so easy to resolve names which
> you'll need to do for all kinds of things such as dealing with things
> like elements reference, attribute references, model group definition
> references, base types, and so on. I would expect that doing this with
> custom code would only be feasible if you can make many simplifying
> assumptions about the complexity of the schemas you will need to handle.
>
>
> Bruno Wassermann wrote:
>
> > Greetings XSD'ers.
> >
> > I have started experimenting with XSD enthusiastically a few days ago,
> > being convinced that it was the right tool for the task I would like
> > to outline. A few days later (today) I am not so sure anymore. Before
> > forgetting about XSD and implementing the below task 'by hand'
> > (querying DOMs directly), please take a look at what I am trying to
> > achieve and be so kind to share your thoughts with me as to the
> > suitability of XSD for this.
> >
> > THE TASK
> > (+) We want to parse WSDL files and specifically (surprise) query the
> > XML Schemas which may be defined in the <wsdl:types> section. [Given
> > that XSD imports are present in the files, xSD does a great job here.]
> >
> > (+) From this data, we want to generate a model that is to be
> > displayed in a tree viewer. We will display a set of <message>s
> > (parsed by a separate piece of code). Expanding these nodes, we want
> > to display any XSD types referenced from within the <message> and in
> > turn the types defining these types. We need a way of differentiating
> > between complex and any of the XSD simple types.
> > (+) Furthermore, a type X may reference an element or a type Y in
> > another (imported) schema. In the tree viewer we want these types (Y,
> > Z, etc.) to appear as children of X.
> > (+) Alternatively, a type X may have a complex type definition which
> > contains an element whose type definition specifies a type in a
> > separate schema.
> > I cannot see a straightforward way to achieve; at least XSD doesn't
> > seem to buy me that much in comparion to generating DOMs of the
> > involved schemas and turning this information into the desired model
> > representation.
> > Please share your wisdom and let me know what you think. Can you see
> > how to achieve this task with XSD having a serious advantage over a
> > custom-built piece of code. Let me know if this needs any further
> > clarification.
> >
> > Many thanks,
> >
> > -- Bruno
> >
> >
> >
|
|
|
| Re: Suitability of XSD for particular task [message #57772 is a reply to message #57747] |
Tue, 15 February 2005 18:07 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------050406000303060802080102
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Bruno,
I haven't seen this before, and I'm surprised to see this effort by Sun
given that DOM PSVI includes a complete model already. I think this was
developed primarily to support implementing JAXB. I doubt it's well
used (and I'm not sure if it is supported should you find problems).
XSD is used heavily at IBM, e.g., WSAD and RAD.
Bruno Wassermann wrote:
>Thank you for your reply, Ed.
>
>As I said before, I agree that XSD is doing a great job wrt loading schemas
>and resolving imports. It is the transformation of the model XSD provides
>you with into a 'more semantic' model of the schemas based on certain
>requirements (i.e. hide some information from the user - if you don't just
>want to display a tree representation of whatever has been parsed (cf.
>XSDEditor)). But I think that is a difficulty introduced by the application
>itself rather than the XSD API :-(
>
>Out of interest, how do you think XSD compares to Sun's XSOM? Have you
>looked at XSOM (https://xsom.dev.java.net/). Looks like XSD provides a bit
>more functionality (e.g. resolve references / types, load schemas from WSDL
>files). It would be interesting to know which implementation has a larger
>user group and whether or not the use cases for which these two
>implementations are used are the same or not.
>
>Regards,
>
>-- Bruno
>
>
>"Ed Merks" <merks@ca.ibm.com> wrote in message
>news:cusmbt$cqq$1@www.eclipse.org...
>
>
>>Bruno,
>>
>>It sounds like XSD will help significantly by loading imported and
>>included schemas properly and automatically, by providing name lookup to
>>find the things you are searching for, and by providing a structured
>>model for analyzing complex content. I would imagine that you would use
>>XSD to load the .wsdl giving you access to all the embedded schemas in
>>the resource's getContents as well as access to any imported or included
>>schema via additional resources in the resource set. Given these, and a
>>type name/namespace you want to lookup, you'd iterate over the schemas
>>in the wsdl resource and do resolveTypeDefinition(namespace, name) until
>>one returns an XSDTypeDefinition with a non-null getSchema, i.e., one
>>that's properly resolved rather than an unattached placeholder. You'd
>>be able to check instanceof
>>XSDComplexTypeDefinition/XSDSimpleTypeDefinition. For a complex type,
>>you could walk its particles and its attribute uses to determine what
>>other types it references.
>>
>>If you don't use XSD, you'll need to do an awful lot yourself. It's not
>>so easy to figure out which schemas to import or include (or to handle
>>the circularity in these) nor is it so easy to resolve names which
>>you'll need to do for all kinds of things such as dealing with things
>>like elements reference, attribute references, model group definition
>>references, base types, and so on. I would expect that doing this with
>>custom code would only be feasible if you can make many simplifying
>>assumptions about the complexity of the schemas you will need to handle.
>>
>>
>>Bruno Wassermann wrote:
>>
>>
>>
>>>Greetings XSD'ers.
>>>
>>>I have started experimenting with XSD enthusiastically a few days ago,
>>>being convinced that it was the right tool for the task I would like
>>>to outline. A few days later (today) I am not so sure anymore. Before
>>>forgetting about XSD and implementing the below task 'by hand'
>>>(querying DOMs directly), please take a look at what I am trying to
>>>achieve and be so kind to share your thoughts with me as to the
>>>suitability of XSD for this.
>>>
>>>THE TASK
>>>(+) We want to parse WSDL files and specifically (surprise) query the
>>>XML Schemas which may be defined in the <wsdl:types> section. [Given
>>>that XSD imports are present in the files, xSD does a great job here.]
>>>
>>>(+) From this data, we want to generate a model that is to be
>>>displayed in a tree viewer. We will display a set of <message>s
>>>(parsed by a separate piece of code). Expanding these nodes, we want
>>>to display any XSD types referenced from within the <message> and in
>>>turn the types defining these types. We need a way of differentiating
>>>between complex and any of the XSD simple types.
>>>(+) Furthermore, a type X may reference an element or a type Y in
>>>another (imported) schema. In the tree viewer we want these types (Y,
>>>Z, etc.) to appear as children of X.
>>>(+) Alternatively, a type X may have a complex type definition which
>>>contains an element whose type definition specifies a type in a
>>>separate schema.
>>>I cannot see a straightforward way to achieve; at least XSD doesn't
>>>seem to buy me that much in comparion to generating DOMs of the
>>>involved schemas and turning this information into the desired model
>>>representation.
>>>Please share your wisdom and let me know what you think. Can you see
>>>how to achieve this task with XSD having a serious advantage over a
>>>custom-built piece of code. Let me know if this needs any further
>>>clarification.
>>>
>>>Many thanks,
>>>
>>>-- Bruno
>>>
>>>
>>>
>>>
>>>
>
>
>
>
--------------050406000303060802080102
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Bruno,<br>
<br>
I haven't seen this before, and I'm surprised to see this effort by Sun
given that DOM PSVI includes a complete model already. I think this
was developed primarily to support implementing JAXB. I doubt it's
well used (and I'm not sure if it is supported should you find
problems). XSD is used heavily at IBM, e.g., WSAD and RAD.<br>
<br>
<br>
Bruno Wassermann wrote:
<blockquote cite="midcutbfc$mvc$1@www.eclipse.org" type="cite">
<pre wrap="">Thank you for your reply, Ed.
As I said before, I agree that XSD is doing a great job wrt loading schemas
and resolving imports. It is the transformation of the model XSD provides
you with into a 'more semantic' model of the schemas based on certain
requirements (i.e. hide some information from the user - if you don't just
want to display a tree representation of whatever has been parsed (cf.
XSDEditor)). But I think that is a difficulty introduced by the application
itself rather than the XSD API :-(
Out of interest, how do you think XSD compares to Sun's XSOM? Have you
looked at XSOM (<a class="moz-txt-link-freetext" href="https://xsom.dev.java.net/">https://xsom.dev.java.net/</a>). Looks like XSD provides a bit
more functionality (e.g. resolve references / types, load schemas from WSDL
files). It would be interesting to know which implementation has a larger
user group and whether or not the use cases for which these two
implementations are used are the same or not.
Regards,
-- Bruno
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com"><merks@ca.ibm.com></a> wrote in message
<a class="moz-txt-link-freetext" href="news:cusmbt$cqq$1@www.eclipse.org">news:cusmbt$cqq$1@www.eclipse.org</a>....
</pre>
<blockquote type="cite">
<pre wrap="">Bruno,
It sounds like XSD will help significantly by loading imported and
included schemas properly and automatically, by providing name lookup to
find the things you are searching for, and by providing a structured
model for analyzing complex content. I would imagine that you would use
XSD to load the .wsdl giving you access to all the embedded schemas in
the resource's getContents as well as access to any imported or included
schema via additional resources in the resource set. Given these, and a
type name/namespace you want to lookup, you'd iterate over the schemas
in the wsdl resource and do resolveTypeDefinition(namespace, name) until
one returns an XSDTypeDefinition with a non-null getSchema, i.e., one
that's properly resolved rather than an unattached placeholder. You'd
be able to check instanceof
XSDComplexTypeDefinition/XSDSimpleTypeDefinition. For a complex type,
you could walk its particles and its attribute uses to determine what
other types it references.
If you don't use XSD, you'll need to do an awful lot yourself. It's not
so easy to figure out which schemas to import or include (or to handle
the circularity in these) nor is it so easy to resolve names which
you'll need to do for all kinds of things such as dealing with things
like elements reference, attribute references, model group definition
references, base types, and so on. I would expect that doing this with
custom code would only be feasible if you can make many simplifying
assumptions about the complexity of the schemas you will need to handle.
Bruno Wassermann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Greetings XSD'ers.
I have started experimenting with XSD enthusiastically a few days ago,
being convinced that it was the right tool for the task I would like
to outline. A few days later (today) I am not so sure anymore. Before
forgetting about XSD and implementing the below task 'by hand'
(querying DOMs directly), please take a look at what I am trying to
achieve and be so kind to share your thoughts with me as to the
suitability of XSD for this.
THE TASK
(+) We want to parse WSDL files and specifically (surprise) query the
XML Schemas which may be defined in the <wsdl:types> section. [Given
that XSD imports are present in the files, xSD does a great job here.]
(+) From this data, we want to generate a model that is to be
displayed in a tree viewer. We will display a set of <message>s
(parsed by a separate piece of code). Expanding these nodes, we want
to display any XSD types referenced from within the <message> and in
turn the types defining these types. We need a way of differentiating
between complex and any of the XSD simple types.
(+) Furthermore, a type X may reference an element or a type Y in
another (imported) schema. In the tree viewer we want these types (Y,
Z, etc.) to appear as children of X.
(+) Alternatively, a type X may have a complex type definition which
contains an element whose type definition specifies a type in a
separate schema.
I cannot see a straightforward way to achieve; at least XSD doesn't
seem to buy me that much in comparion to generating DOMs of the
involved schemas and turning this information into the desired model
representation.
Please share your wisdom and let me know what you think. Can you see
how to achieve this task with XSD having a serious advantage over a
custom-built piece of code. Let me know if this needs any further
clarification.
Many thanks,
-- Bruno
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------050406000303060802080102--
|
|
|
| Re: Suitability of XSD for particular task [message #593999 is a reply to message #57698] |
Tue, 15 February 2005 11:28 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Bruno,
It sounds like XSD will help significantly by loading imported and
included schemas properly and automatically, by providing name lookup to
find the things you are searching for, and by providing a structured
model for analyzing complex content. I would imagine that you would use
XSD to load the .wsdl giving you access to all the embedded schemas in
the resource's getContents as well as access to any imported or included
schema via additional resources in the resource set. Given these, and a
type name/namespace you want to lookup, you'd iterate over the schemas
in the wsdl resource and do resolveTypeDefinition(namespace, name) until
one returns an XSDTypeDefinition with a non-null getSchema, i.e., one
that's properly resolved rather than an unattached placeholder. You'd
be able to check instanceof
XSDComplexTypeDefinition/XSDSimpleTypeDefinition. For a complex type,
you could walk its particles and its attribute uses to determine what
other types it references.
If you don't use XSD, you'll need to do an awful lot yourself. It's not
so easy to figure out which schemas to import or include (or to handle
the circularity in these) nor is it so easy to resolve names which
you'll need to do for all kinds of things such as dealing with things
like elements reference, attribute references, model group definition
references, base types, and so on. I would expect that doing this with
custom code would only be feasible if you can make many simplifying
assumptions about the complexity of the schemas you will need to handle.
Bruno Wassermann wrote:
> Greetings XSD'ers.
>
> I have started experimenting with XSD enthusiastically a few days ago,
> being convinced that it was the right tool for the task I would like
> to outline. A few days later (today) I am not so sure anymore. Before
> forgetting about XSD and implementing the below task 'by hand'
> (querying DOMs directly), please take a look at what I am trying to
> achieve and be so kind to share your thoughts with me as to the
> suitability of XSD for this.
>
> THE TASK
> (+) We want to parse WSDL files and specifically (surprise) query the
> XML Schemas which may be defined in the <wsdl:types> section. [Given
> that XSD imports are present in the files, xSD does a great job here.]
>
> (+) From this data, we want to generate a model that is to be
> displayed in a tree viewer. We will display a set of <message>s
> (parsed by a separate piece of code). Expanding these nodes, we want
> to display any XSD types referenced from within the <message> and in
> turn the types defining these types. We need a way of differentiating
> between complex and any of the XSD simple types.
> (+) Furthermore, a type X may reference an element or a type Y in
> another (imported) schema. In the tree viewer we want these types (Y,
> Z, etc.) to appear as children of X.
> (+) Alternatively, a type X may have a complex type definition which
> contains an element whose type definition specifies a type in a
> separate schema.
> I cannot see a straightforward way to achieve; at least XSD doesn't
> seem to buy me that much in comparion to generating DOMs of the
> involved schemas and turning this information into the desired model
> representation.
> Please share your wisdom and let me know what you think. Can you see
> how to achieve this task with XSD having a serious advantage over a
> custom-built piece of code. Let me know if this needs any further
> clarification.
>
> Many thanks,
>
> -- Bruno
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Suitability of XSD for particular task [message #594014 is a reply to message #57722] |
Tue, 15 February 2005 17:28 |
Bruno Wassermann
Messages: 21
Registered: July 2009 |
Junior Member |
|
|
Thank you for your reply, Ed.
As I said before, I agree that XSD is doing a great job wrt loading schemas
and resolving imports. It is the transformation of the model XSD provides
you with into a 'more semantic' model of the schemas based on certain
requirements (i.e. hide some information from the user - if you don't just
want to display a tree representation of whatever has been parsed (cf.
XSDEditor)). But I think that is a difficulty introduced by the application
itself rather than the XSD API :-(
Out of interest, how do you think XSD compares to Sun's XSOM? Have you
looked at XSOM (https://xsom.dev.java.net/). Looks like XSD provides a bit
more functionality (e.g. resolve references / types, load schemas from WSDL
files). It would be interesting to know which implementation has a larger
user group and whether or not the use cases for which these two
implementations are used are the same or not.
Regards,
-- Bruno
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:cusmbt$cqq$1@www.eclipse.org...
> Bruno,
>
> It sounds like XSD will help significantly by loading imported and
> included schemas properly and automatically, by providing name lookup to
> find the things you are searching for, and by providing a structured
> model for analyzing complex content. I would imagine that you would use
> XSD to load the .wsdl giving you access to all the embedded schemas in
> the resource's getContents as well as access to any imported or included
> schema via additional resources in the resource set. Given these, and a
> type name/namespace you want to lookup, you'd iterate over the schemas
> in the wsdl resource and do resolveTypeDefinition(namespace, name) until
> one returns an XSDTypeDefinition with a non-null getSchema, i.e., one
> that's properly resolved rather than an unattached placeholder. You'd
> be able to check instanceof
> XSDComplexTypeDefinition/XSDSimpleTypeDefinition. For a complex type,
> you could walk its particles and its attribute uses to determine what
> other types it references.
>
> If you don't use XSD, you'll need to do an awful lot yourself. It's not
> so easy to figure out which schemas to import or include (or to handle
> the circularity in these) nor is it so easy to resolve names which
> you'll need to do for all kinds of things such as dealing with things
> like elements reference, attribute references, model group definition
> references, base types, and so on. I would expect that doing this with
> custom code would only be feasible if you can make many simplifying
> assumptions about the complexity of the schemas you will need to handle.
>
>
> Bruno Wassermann wrote:
>
> > Greetings XSD'ers.
> >
> > I have started experimenting with XSD enthusiastically a few days ago,
> > being convinced that it was the right tool for the task I would like
> > to outline. A few days later (today) I am not so sure anymore. Before
> > forgetting about XSD and implementing the below task 'by hand'
> > (querying DOMs directly), please take a look at what I am trying to
> > achieve and be so kind to share your thoughts with me as to the
> > suitability of XSD for this.
> >
> > THE TASK
> > (+) We want to parse WSDL files and specifically (surprise) query the
> > XML Schemas which may be defined in the <wsdl:types> section. [Given
> > that XSD imports are present in the files, xSD does a great job here.]
> >
> > (+) From this data, we want to generate a model that is to be
> > displayed in a tree viewer. We will display a set of <message>s
> > (parsed by a separate piece of code). Expanding these nodes, we want
> > to display any XSD types referenced from within the <message> and in
> > turn the types defining these types. We need a way of differentiating
> > between complex and any of the XSD simple types.
> > (+) Furthermore, a type X may reference an element or a type Y in
> > another (imported) schema. In the tree viewer we want these types (Y,
> > Z, etc.) to appear as children of X.
> > (+) Alternatively, a type X may have a complex type definition which
> > contains an element whose type definition specifies a type in a
> > separate schema.
> > I cannot see a straightforward way to achieve; at least XSD doesn't
> > seem to buy me that much in comparion to generating DOMs of the
> > involved schemas and turning this information into the desired model
> > representation.
> > Please share your wisdom and let me know what you think. Can you see
> > how to achieve this task with XSD having a serious advantage over a
> > custom-built piece of code. Let me know if this needs any further
> > clarification.
> >
> > Many thanks,
> >
> > -- Bruno
> >
> >
> >
|
|
|
| Re: Suitability of XSD for particular task [message #594033 is a reply to message #57747] |
Tue, 15 February 2005 18:07 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------050406000303060802080102
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Bruno,
I haven't seen this before, and I'm surprised to see this effort by Sun
given that DOM PSVI includes a complete model already. I think this was
developed primarily to support implementing JAXB. I doubt it's well
used (and I'm not sure if it is supported should you find problems).
XSD is used heavily at IBM, e.g., WSAD and RAD.
Bruno Wassermann wrote:
>Thank you for your reply, Ed.
>
>As I said before, I agree that XSD is doing a great job wrt loading schemas
>and resolving imports. It is the transformation of the model XSD provides
>you with into a 'more semantic' model of the schemas based on certain
>requirements (i.e. hide some information from the user - if you don't just
>want to display a tree representation of whatever has been parsed (cf.
>XSDEditor)). But I think that is a difficulty introduced by the application
>itself rather than the XSD API :-(
>
>Out of interest, how do you think XSD compares to Sun's XSOM? Have you
>looked at XSOM (https://xsom.dev.java.net/). Looks like XSD provides a bit
>more functionality (e.g. resolve references / types, load schemas from WSDL
>files). It would be interesting to know which implementation has a larger
>user group and whether or not the use cases for which these two
>implementations are used are the same or not.
>
>Regards,
>
>-- Bruno
>
>
>"Ed Merks" <merks@ca.ibm.com> wrote in message
>news:cusmbt$cqq$1@www.eclipse.org...
>
>
>>Bruno,
>>
>>It sounds like XSD will help significantly by loading imported and
>>included schemas properly and automatically, by providing name lookup to
>>find the things you are searching for, and by providing a structured
>>model for analyzing complex content. I would imagine that you would use
>>XSD to load the .wsdl giving you access to all the embedded schemas in
>>the resource's getContents as well as access to any imported or included
>>schema via additional resources in the resource set. Given these, and a
>>type name/namespace you want to lookup, you'd iterate over the schemas
>>in the wsdl resource and do resolveTypeDefinition(namespace, name) until
>>one returns an XSDTypeDefinition with a non-null getSchema, i.e., one
>>that's properly resolved rather than an unattached placeholder. You'd
>>be able to check instanceof
>>XSDComplexTypeDefinition/XSDSimpleTypeDefinition. For a complex type,
>>you could walk its particles and its attribute uses to determine what
>>other types it references.
>>
>>If you don't use XSD, you'll need to do an awful lot yourself. It's not
>>so easy to figure out which schemas to import or include (or to handle
>>the circularity in these) nor is it so easy to resolve names which
>>you'll need to do for all kinds of things such as dealing with things
>>like elements reference, attribute references, model group definition
>>references, base types, and so on. I would expect that doing this with
>>custom code would only be feasible if you can make many simplifying
>>assumptions about the complexity of the schemas you will need to handle.
>>
>>
>>Bruno Wassermann wrote:
>>
>>
>>
>>>Greetings XSD'ers.
>>>
>>>I have started experimenting with XSD enthusiastically a few days ago,
>>>being convinced that it was the right tool for the task I would like
>>>to outline. A few days later (today) I am not so sure anymore. Before
>>>forgetting about XSD and implementing the below task 'by hand'
>>>(querying DOMs directly), please take a look at what I am trying to
>>>achieve and be so kind to share your thoughts with me as to the
>>>suitability of XSD for this.
>>>
>>>THE TASK
>>>(+) We want to parse WSDL files and specifically (surprise) query the
>>>XML Schemas which may be defined in the <wsdl:types> section. [Given
>>>that XSD imports are present in the files, xSD does a great job here.]
>>>
>>>(+) From this data, we want to generate a model that is to be
>>>displayed in a tree viewer. We will display a set of <message>s
>>>(parsed by a separate piece of code). Expanding these nodes, we want
>>>to display any XSD types referenced from within the <message> and in
>>>turn the types defining these types. We need a way of differentiating
>>>between complex and any of the XSD simple types.
>>>(+) Furthermore, a type X may reference an element or a type Y in
>>>another (imported) schema. In the tree viewer we want these types (Y,
>>>Z, etc.) to appear as children of X.
>>>(+) Alternatively, a type X may have a complex type definition which
>>>contains an element whose type definition specifies a type in a
>>>separate schema.
>>>I cannot see a straightforward way to achieve; at least XSD doesn't
>>>seem to buy me that much in comparion to generating DOMs of the
>>>involved schemas and turning this information into the desired model
>>>representation.
>>>Please share your wisdom and let me know what you think. Can you see
>>>how to achieve this task with XSD having a serious advantage over a
>>>custom-built piece of code. Let me know if this needs any further
>>>clarification.
>>>
>>>Many thanks,
>>>
>>>-- Bruno
>>>
>>>
>>>
>>>
>>>
>
>
>
>
--------------050406000303060802080102
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Bruno,<br>
<br>
I haven't seen this before, and I'm surprised to see this effort by Sun
given that DOM PSVI includes a complete model already. I think this
was developed primarily to support implementing JAXB. I doubt it's
well used (and I'm not sure if it is supported should you find
problems). XSD is used heavily at IBM, e.g., WSAD and RAD.<br>
<br>
<br>
Bruno Wassermann wrote:
<blockquote cite="midcutbfc$mvc$1@www.eclipse.org" type="cite">
<pre wrap="">Thank you for your reply, Ed.
As I said before, I agree that XSD is doing a great job wrt loading schemas
and resolving imports. It is the transformation of the model XSD provides
you with into a 'more semantic' model of the schemas based on certain
requirements (i.e. hide some information from the user - if you don't just
want to display a tree representation of whatever has been parsed (cf.
XSDEditor)). But I think that is a difficulty introduced by the application
itself rather than the XSD API :-(
Out of interest, how do you think XSD compares to Sun's XSOM? Have you
looked at XSOM (<a class="moz-txt-link-freetext" href="https://xsom.dev.java.net/">https://xsom.dev.java.net/</a>). Looks like XSD provides a bit
more functionality (e.g. resolve references / types, load schemas from WSDL
files). It would be interesting to know which implementation has a larger
user group and whether or not the use cases for which these two
implementations are used are the same or not.
Regards,
-- Bruno
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com"><merks@ca.ibm.com></a> wrote in message
<a class="moz-txt-link-freetext" href="news:cusmbt$cqq$1@www.eclipse.org">news:cusmbt$cqq$1@www.eclipse.org</a>....
</pre>
<blockquote type="cite">
<pre wrap="">Bruno,
It sounds like XSD will help significantly by loading imported and
included schemas properly and automatically, by providing name lookup to
find the things you are searching for, and by providing a structured
model for analyzing complex content. I would imagine that you would use
XSD to load the .wsdl giving you access to all the embedded schemas in
the resource's getContents as well as access to any imported or included
schema via additional resources in the resource set. Given these, and a
type name/namespace you want to lookup, you'd iterate over the schemas
in the wsdl resource and do resolveTypeDefinition(namespace, name) until
one returns an XSDTypeDefinition with a non-null getSchema, i.e., one
that's properly resolved rather than an unattached placeholder. You'd
be able to check instanceof
XSDComplexTypeDefinition/XSDSimpleTypeDefinition. For a complex type,
you could walk its particles and its attribute uses to determine what
other types it references.
If you don't use XSD, you'll need to do an awful lot yourself. It's not
so easy to figure out which schemas to import or include (or to handle
the circularity in these) nor is it so easy to resolve names which
you'll need to do for all kinds of things such as dealing with things
like elements reference, attribute references, model group definition
references, base types, and so on. I would expect that doing this with
custom code would only be feasible if you can make many simplifying
assumptions about the complexity of the schemas you will need to handle.
Bruno Wassermann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Greetings XSD'ers.
I have started experimenting with XSD enthusiastically a few days ago,
being convinced that it was the right tool for the task I would like
to outline. A few days later (today) I am not so sure anymore. Before
forgetting about XSD and implementing the below task 'by hand'
(querying DOMs directly), please take a look at what I am trying to
achieve and be so kind to share your thoughts with me as to the
suitability of XSD for this.
THE TASK
(+) We want to parse WSDL files and specifically (surprise) query the
XML Schemas which may be defined in the <wsdl:types> section. [Given
that XSD imports are present in the files, xSD does a great job here.]
(+) From this data, we want to generate a model that is to be
displayed in a tree viewer. We will display a set of <message>s
(parsed by a separate piece of code). Expanding these nodes, we want
to display any XSD types referenced from within the <message> and in
turn the types defining these types. We need a way of differentiating
between complex and any of the XSD simple types.
(+) Furthermore, a type X may reference an element or a type Y in
another (imported) schema. In the tree viewer we want these types (Y,
Z, etc.) to appear as children of X.
(+) Alternatively, a type X may have a complex type definition which
contains an element whose type definition specifies a type in a
separate schema.
I cannot see a straightforward way to achieve; at least XSD doesn't
seem to buy me that much in comparion to generating DOMs of the
involved schemas and turning this information into the desired model
representation.
Please share your wisdom and let me know what you think. Can you see
how to achieve this task with XSD having a serious advantage over a
custom-built piece of code. Let me know if this needs any further
clarification.
Many thanks,
-- Bruno
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------050406000303060802080102--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Wed Apr 24 20:31:44 GMT 2024
Powered by FUDForum. Page generated in 0.03439 seconds |
] 
Search
Help
Register
Login
Home
