You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by Andrew Harrison <a....@cs.cardiff.ac.uk> on 2007/01/24 14:03:44 UTC
XmlSchema API
Hi,
I've been working with the XmlSchema API and have some questions
about it.
There are a number of abstract super classes (e.g. XmlSchemaContent)
that do not expose properties shared by all their children (for
example getAttributes() in the given example). This means I have to
do instanceof on each child to get the attributes. Could anyone
explain the design decision behind this?
Also, getting a particle from a ComplexType seems difficult. If the
type uses the schema shorthand and omits the content model, then I
need to get the particle from the type. But if the content model is
present, then I get the particle from that. While this makes literal
sense, the shorthand in the schema implies a content model defining a
restriction on anyType - a default content model for complex content.
I'm surprised this isn't modeled in the API. Perhaps I'm navigating
through the schema in the wrong way.
Any clarification greatly appreciated.
cheers,
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: XmlSchema API
Posted by Andrew Harrison <a....@cs.cardiff.ac.uk>.
Thanks for the comments. I didn't mean to open a can of worms 8^)
I agree that Schema is a mess and shoe-horning it into programming
language constructs is doomed. Hence I can see the logic in
reflecting the schema exactly, as XmlSchema does. The problem I've
found with this approach is that you end up with a bunch of Java
classes that are as difficult to work with as the Schema itself,
which leads to the conclusion that one might as well work with the
xml and save on overhead.
sort of related... I'm working on a Schema object model which sits
halfway between the 'reflect the xml exactly' approach and the
'generate Java classes' approach. The areas I'm working in require
dynamic client capabilities and I've always found generating classes
cumbersome, error prone and very slow (particularly if you're
compiling at runtime). And if you're discovering and invoking
services dynamically, you end up using Java reflection on the classes
which means you're restricted to this API anyway. Hence the stuff I'm
working on is an attempt to expose the schema using a reflection-like
API to set and get data without generating code.
cheers,
Andrew
On 25 Jan 2007, at 07:32, Dennis Sosnoski wrote:
> Ah, well, that explains it then - basing OO software on a design
> from Microsoft is like basing humanitarian initiatives on U.S.
> foreign policy. :-)
>
> More seriously, I've been working with an object model for Schema
> myself, for use with JiBX code generation. Schema is a mess, and
> attempting to translate it into any programming language model is
> bound to run into great difficulties. But the .Net model looks
> especially lame - they don't even attempt to provide clean
> interfaces enforcing proper structuring, for instance - and the
> Commons implementation seems to suffer from some of the same
> drawbacks. It's also totally undocumented, which is especially bad
> when it comes to something as complex as Schema. That's part of why
> I decided to do my own, rather than try to work with one of the
> existing models.
>
> The XMLSchema project badly needs complete documentation if it's
> going to be useful to anyone outside the core of developers who
> have actually worked on the internals.
>
> - Dennis
>
> Dennis M. Sosnoski
> SOA and Web Services in Java
> Training and Consulting
> http://www.sosnoski.com - http://www.sosnoski.co.nz
> Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117
>
>
>
> Davanum Srinivas wrote:
>> Andrew,
>>
>> Originally the code was an attempt to port .NET's
>> System.Xml.Schema.XmlSchema, but has evolved over a period of time to
>> the point that it is today. Even when we try to fix something for
>> Axis2, we pore over the code, put breakpoints, look at the actual
>> contents in the object hierarchy and code accordingly :(
>>
>> -- dims
>>
>> On 1/24/07, Andrew Harrison <a....@cs.cardiff.ac.uk> wrote:
>>> Hi,
>>>
>>> I've been working with the XmlSchema API and have some questions
>>> about it.
>>>
>>> There are a number of abstract super classes (e.g. XmlSchemaContent)
>>> that do not expose properties shared by all their children (for
>>> example getAttributes() in the given example). This means I have to
>>> do instanceof on each child to get the attributes. Could anyone
>>> explain the design decision behind this?
>>>
>>> Also, getting a particle from a ComplexType seems difficult. If the
>>> type uses the schema shorthand and omits the content model, then I
>>> need to get the particle from the type. But if the content model is
>>> present, then I get the particle from that. While this makes literal
>>> sense, the shorthand in the schema implies a content model
>>> defining a
>>> restriction on anyType - a default content model for complex
>>> content.
>>> I'm surprised this isn't modeled in the API. Perhaps I'm navigating
>>> through the schema in the wrong way.
>>>
>>> Any clarification greatly appreciated.
>>>
>>> cheers,
>>>
>>> Andrew
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: commons-dev-help@ws.apache.org
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
Andrew Harrison
School of Computer Science, Cardiff.
a.b.harrison@cs.cf.ac.uk
Tel: +44(0)29 208 76964
Mobile: +44(0)777 93 888 16
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: XmlSchema API
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Ah, well, that explains it then - basing OO software on a design from
Microsoft is like basing humanitarian initiatives on U.S. foreign
policy. :-)
More seriously, I've been working with an object model for Schema
myself, for use with JiBX code generation. Schema is a mess, and
attempting to translate it into any programming language model is bound
to run into great difficulties. But the .Net model looks especially lame
- they don't even attempt to provide clean interfaces enforcing proper
structuring, for instance - and the Commons implementation seems to
suffer from some of the same drawbacks. It's also totally undocumented,
which is especially bad when it comes to something as complex as Schema.
That's part of why I decided to do my own, rather than try to work with
one of the existing models.
The XMLSchema project badly needs complete documentation if it's going
to be useful to anyone outside the core of developers who have actually
worked on the internals.
- Dennis
Dennis M. Sosnoski
SOA and Web Services in Java
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117
Davanum Srinivas wrote:
> Andrew,
>
> Originally the code was an attempt to port .NET's
> System.Xml.Schema.XmlSchema, but has evolved over a period of time to
> the point that it is today. Even when we try to fix something for
> Axis2, we pore over the code, put breakpoints, look at the actual
> contents in the object hierarchy and code accordingly :(
>
> -- dims
>
> On 1/24/07, Andrew Harrison <a....@cs.cardiff.ac.uk> wrote:
>> Hi,
>>
>> I've been working with the XmlSchema API and have some questions
>> about it.
>>
>> There are a number of abstract super classes (e.g. XmlSchemaContent)
>> that do not expose properties shared by all their children (for
>> example getAttributes() in the given example). This means I have to
>> do instanceof on each child to get the attributes. Could anyone
>> explain the design decision behind this?
>>
>> Also, getting a particle from a ComplexType seems difficult. If the
>> type uses the schema shorthand and omits the content model, then I
>> need to get the particle from the type. But if the content model is
>> present, then I get the particle from that. While this makes literal
>> sense, the shorthand in the schema implies a content model defining a
>> restriction on anyType - a default content model for complex content.
>> I'm surprised this isn't modeled in the API. Perhaps I'm navigating
>> through the schema in the wrong way.
>>
>> Any clarification greatly appreciated.
>>
>> cheers,
>>
>> Andrew
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: commons-dev-help@ws.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: XmlSchema API
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi,
I did some development/bug fixing /feature completion for XMLSchema
sometime back (since we needed it to be complete for use in Axis2). I
do agree its a bit cumbersome to navigate and is missing shortcuts.
However what I noticed is that the object structure refelects the XML
Schema specification very strongly (I got to know about the .net a few
minutes ago from Dim's answer :)). Hence it did not feel right to
modify it.
Ajith
On 1/24/07, Davanum Srinivas <da...@gmail.com> wrote:
> Andrew,
>
> Originally the code was an attempt to port .NET's
> System.Xml.Schema.XmlSchema, but has evolved over a period of time to
> the point that it is today. Even when we try to fix something for
> Axis2, we pore over the code, put breakpoints, look at the actual
> contents in the object hierarchy and code accordingly :(
>
> -- dims
>
> On 1/24/07, Andrew Harrison <a....@cs.cardiff.ac.uk> wrote:
> > Hi,
> >
> > I've been working with the XmlSchema API and have some questions
> > about it.
> >
> > There are a number of abstract super classes (e.g. XmlSchemaContent)
> > that do not expose properties shared by all their children (for
> > example getAttributes() in the given example). This means I have to
> > do instanceof on each child to get the attributes. Could anyone
> > explain the design decision behind this?
> >
> > Also, getting a particle from a ComplexType seems difficult. If the
> > type uses the schema shorthand and omits the content model, then I
> > need to get the particle from the type. But if the content model is
> > present, then I get the particle from that. While this makes literal
> > sense, the shorthand in the schema implies a content model defining a
> > restriction on anyType - a default content model for complex content.
> > I'm surprised this isn't modeled in the API. Perhaps I'm navigating
> > through the schema in the wrong way.
> >
> > Any clarification greatly appreciated.
> >
> > cheers,
> >
> > Andrew
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: commons-dev-help@ws.apache.org
> >
> >
>
>
> --
> Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>
--
Ajith Ranabahu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: XmlSchema API
Posted by Davanum Srinivas <da...@gmail.com>.
Andrew,
Originally the code was an attempt to port .NET's
System.Xml.Schema.XmlSchema, but has evolved over a period of time to
the point that it is today. Even when we try to fix something for
Axis2, we pore over the code, put breakpoints, look at the actual
contents in the object hierarchy and code accordingly :(
-- dims
On 1/24/07, Andrew Harrison <a....@cs.cardiff.ac.uk> wrote:
> Hi,
>
> I've been working with the XmlSchema API and have some questions
> about it.
>
> There are a number of abstract super classes (e.g. XmlSchemaContent)
> that do not expose properties shared by all their children (for
> example getAttributes() in the given example). This means I have to
> do instanceof on each child to get the attributes. Could anyone
> explain the design decision behind this?
>
> Also, getting a particle from a ComplexType seems difficult. If the
> type uses the schema shorthand and omits the content model, then I
> need to get the particle from the type. But if the content model is
> present, then I get the particle from that. While this makes literal
> sense, the shorthand in the schema implies a content model defining a
> restriction on anyType - a default content model for complex content.
> I'm surprised this isn't modeled in the API. Perhaps I'm navigating
> through the schema in the wrong way.
>
> Any clarification greatly appreciated.
>
> cheers,
>
> Andrew
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org