Re: JDOM and javax.* classes

[Jeffrey Rodriguez <je...@hotmail.com>]

Ted Leung said

>I don't like the solution of using a DOM tree as a symbol table.
>It doesn't really get you out of symbol table building, and it's just
>bloated.  I don't see any reason why symbol table construction couldn't
>be driven off of  SAX or XNI.
>

Ted the following are the reasons why we use the DOM API to parse
Schemas:

1) It is a well known standard API that allows random access to the
   Schema document.
2) DOM core has been around for a while ago and it is more robust
   that any other adhoc way of doing it ( either through SAX, etc ) or
   DOM oriented APIs.
3) Code reusability.

4) Time ( we did not have to write more code).

5) Future access  to Schemas for tool writers.

We thought about using SAX and our own internal structures but by the
time that we finish designing it the result was something similar to the
DOM.

Granted we could have done this in a very elegant and smart way but the 
goals were as I said above, easy of maintenance (1), robustness (2), code 
reusability (3), and time, etc.

You could say that, yes the DOM is bloated and we should have use
a lighter implementation. Yes this may be done in future implementations
of Schema but our first goal was to get an implementation that works.



> > Perhaps we're back to figuring out how to do dependencies
> > among the various layers. Schema validation can be seen as
> > just another layer and unless it carries along its own tree
> > implementation then it should "state" that it depends on
> > DOM. Perhaps a tool of some sort... someone could write
> > some very cool stuff for the web site to manage contributions
> > and building custom jar files based on the dependency info.
> > Any takers?
>
>I'd prefer to see Schema not depend on the DOM.  I agree that
>this kind of web-based configuration tool would be very cool.
>

Ted, the DOM is just a convenient way to represent and traverse a Schema.
Even tough we use the DOM API, the Schema architecture in Xerces 
implementation does not dependend on it.

In other words we could replace the TraverseSchema module with a
better, lighter implementation tomorrow if the need arises.

In the other hand a DOM API being a standard provides opportunities
for tool vendors to create  Grammar Editors and other interesting tools
to access a Schemas. This idea is not that farfetched look
at how cool XML-Spy is.


My 2 cents on this,

                  Jeffrey Rodriguez
                  IBM Silicon Valley
                  XML Development



_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

Re: JDOM and javax.* classes

[Ted Leung <tw...@sauria.com>]

----- Original Message -----
From: "Jeffrey Rodriguez" <je...@hotmail.com>
To: <xe...@xml.apache.org>
Sent: Thursday, September 14, 2000 9:33 AM
Subject: Re: JDOM and javax.* classes


> Ted Leung said
>
> >I don't like the solution of using a DOM tree as a symbol table.
> >It doesn't really get you out of symbol table building, and it's just
> >bloated.  I don't see any reason why symbol table construction couldn't
> >be driven off of  SAX or XNI.
> >
>
> Ted the following are the reasons why we use the DOM API to parse
> Schemas:
>
> 1) It is a well known standard API that allows random access to the
>    Schema document.
> 2) DOM core has been around for a while ago and it is more robust
>    that any other adhoc way of doing it ( either through SAX, etc ) or
>    DOM oriented APIs.
> 3) Code reusability.
>
> 4) Time ( we did not have to write more code).
>
> 5) Future access  to Schemas for tool writers.

Fine.  I understand the issues.  I did work on the code, remember?

> We thought about using SAX and our own internal structures but by the
> time that we finish designing it the result was something similar to the
> DOM.
>
> Granted we could have done this in a very elegant and smart way but the
> goals were as I said above, easy of maintenance (1), robustness (2), code
> reusability (3), and time, etc.
>
> You could say that, yes the DOM is bloated and we should have use
> a lighter implementation. Yes this may be done in future implementations
> of Schema but our first goal was to get an implementation that works.
>

We are talking about a next generation or second round implementation here,
aren't we?   I'm not saying I want the current schema implementation ripped
out and done without the DOM.  I'm saying that it would be better from my
point of view if Schema didn't depend on DOM in the next version of the
parser.

>
> > > Perhaps we're back to figuring out how to do dependencies
> > > among the various layers. Schema validation can be seen as
> > > just another layer and unless it carries along its own tree
> > > implementation then it should "state" that it depends on
> > > DOM. Perhaps a tool of some sort... someone could write
> > > some very cool stuff for the web site to manage contributions
> > > and building custom jar files based on the dependency info.
> > > Any takers?
> >
> >I'd prefer to see Schema not depend on the DOM.  I agree that
> >this kind of web-based configuration tool would be very cool.
> >
>
> Ted, the DOM is just a convenient way to represent and traverse a Schema.
> Even tough we use the DOM API, the Schema architecture in Xerces
> implementation does not dependend on it.
>
> In other words we could replace the TraverseSchema module with a
> better, lighter implementation tomorrow if the need arises.
>
> In the other hand a DOM API being a standard provides opportunities
> for tool vendors to create  Grammar Editors and other interesting tools
> to access a Schemas. This idea is not that farfetched look
> at how cool XML-Spy is.
>
>
> My 2 cents on this,
>
>                   Jeffrey Rodriguez
>                   IBM Silicon Valley
>                   XML Development
>
>
>
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
> Share information about yourself, create your own public profile at
> http://profiles.msn.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>