Hi David,

Thanks for posting this detailed information!  Although I'm afraid this
might be far too esoteric for this broad audience, as someone who's been
involved with a couple of schema validation implementations, I can't help
but ask you about this particular bullet in the list:

[[
It's robust enough that it is a self-hosted XML compiler. In particular, we
don't have a hand-built schema parser. We use the automatically compiled
XMLBean,
compiled from schema-for-schema, to parse schema. I'm not aware of other
binding tools that have enough depth of schema support to do that.
]]

That's certainly not the road we went down in either Xerces-J 1 or 2.  :)
How does this approach handle things like the schema unique particle
attribution or element declarations consistent constraints?  Clearly you
could parse schema documents simply using information from the
schema-for-schemas, but using that alone, surely it's not possible to
handle all conditions imposed on valid schemas by that spec.

I'm raising this out of curiosity, not as any kind of objection.  I would
like to think that, if this code makes it into Apache--a point on which I'm
agnostic for now--that synergies with related code like Xerces's schema
support could be exploited wherever possible; but as Andy says in another
note, competition is sometimes neither unavoidable nor even undesirable.
:)

Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone:  905-413-3519, T/L 969-3519
E-mail:  [EMAIL PROTECTED]




|---------+---------------------------->
|         |           "David Bau"      |
|         |           <[EMAIL PROTECTED]|
|         |           m>               |
|         |                            |
|         |           07/03/2003 04:55 |
|         |           PM               |
|         |           Please respond to|
|         |           general          |
|         |                            |
|---------+---------------------------->
  
>---------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                    
                                                         |
  |       To:       "Jakarta General List" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, 
<[EMAIL PROTECTED]>               |
  |       cc:                                                                          
                                                         |
  |       Subject:  XML Beans details                                                  
                                                         |
  |                                                                                    
                                                         |
  |                                                                                    
                                                         |
  
>---------------------------------------------------------------------------------------------------------------------------------------------|



On 7/3/03 4:22 PM "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:
>
> On 7/3/03 3:50 PM, "Cliff Schmidt" <[EMAIL PROTECTED]> wrote:
> >
> > this might be a good time for David Bau, the architect behind
> > XMLBeans, to jump in with his views.
>
> Okay.  It sounds like there are some issues which warrant
> this over others.
> I could see this being useful in things like web services as
> well...  Limit
> object creation/serialization and yada yada yada...  Though
> from reading the
> 10k foot view you could support JAXB if you wanted to.  Just
> an element of

Yeah, limiting object creation is one of the particular benefits
to the approach.  Also JAXB is of particular interest to us!
We're particularly interested in JSR 222.

I started writing up some details to the Q of "what is XML Beans
and how does it compare to X Y and Z?" but it was getting long
so I posted it on a wiki page

http://nagoya.apache.org/wiki/apachewiki.cgi?XmlBeansExplanation

David Bau
XML Beans architect

---------------------------------------------------------------------
In case of troubles, e-mail:     [EMAIL PROTECTED]
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]

Reply via email to