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 <[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]
Andrew Harrison
School of Computer Science, Cardiff.
[EMAIL PROTECTED]
Tel: +44(0)29 208 76964
Mobile: +44(0)777 93 888 16
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
