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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
