You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Ed Staub <es...@mediaone.net> on 2000/07/14 23:34:45 UTC
[Xerces2] What is CORE?
I think I've detected an inconsistency in the current consensus on what a
core would look like. Basically: is there a tree in it or not?
I think that folks using event-driven API's like SAX2 would not want to be
burdened with the overhead of creating a tree.
On the other hand, there's a lot of reusability to be provided by a common
layer under DOM, JDOM, XPath, et al. (Brett, in response to
http://xml-archive.webweaving.org/xml-archive-general/2274.html, I'm
thinking option #3.)
So instead of seeing
DOM SAX2 JDOM
| | |
------------
|
CORE
I see two levels of "core", an event core underneath a tree core.
Perhaps something like the Xalan might be used.
other
tree
DOM JDOM users
| | |
------------
|
| other
TREE event
SAX2 CORE listeners
| | |
-------------
|
EVENT
CORE
This may have been really obvious to everyone.
If so, sorry to belabor it.
-Ed
Re: [Xerces2] What is CORE?
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
Sure. I'm not suggesting that Xerces doesn't already have a lot of this in
place.
I've been approaching this (personally) with a clean-room POV, which is sort
of what I think other contributors have in mind. I have an interest in this
through FOP; I'd like to help define requirements, and drop out of the
process afterwards. We're already drifting into talking about performance
and stuff that smacks of implementation; too low-level.
Arved Sandstrom
At 02:49 PM 7/15/00 -0700, Ted Leung wrote:
>
>----- Original Message -----
>From: "James Duncan Davidson" <ja...@eng.sun.com>
>To: <xe...@xml.apache.org>
>Sent: Friday, July 14, 2000 9:31 PM
>Subject: Re: [Xerces2] What is CORE?
>
>
>> on 7/14/00 4:08 PM, Arved Sandstrom at Arved_37@chebucto.ns.ca wrote:
>>
>> > I think the production of a tree is definitely one notch higher up in
>> > processing than SAX-style production of events. I think the actual
>"event
>> > core" need not be SAX - witness expat, which is very successful.
>>
>> Right.. And it need not be Event -- it could be pull. In which case a
>little
>> thread can sit in the SAXEventProducer and pull next chunk and fire SAX
>> events based on that.
>>
>> > I see a compact, fast parser that produces raw Xerces2 events. A SAX2
>API
>> > builds on that. An integral Xerces2 DOM API uses Xerces2 events; it
>would
>> > also be possible for outside DOM implementations to use the SAX API.
>>
>
>The Xerces1 parser has an internal API that gets turned into SAX events or
>into
>a DOM (in the case of the deferred DOM). The only problem with that API is
>that is uses ints, which has been widely cited as a problem. I wonder if
>this is
>really a problem or whether it's just that the documentation in the code is
>horrible.
>
>>From some of the other discussions we've been having, it seems like the
>maintainability
>complaints might be addressed by modifying this API away from ints and
>toward
>StringHolders, StringRecyclers, or StringTrashCompactors. Unfortunately,
>that's not
>all that revolutionary.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>
Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"
Re: [Xerces2] What is CORE?
Posted by Costin Manolache <co...@eng.sun.com>.
Mike Pogue wrote:
> Yep, as long as performance is maintained, I think this could be a Good Thing.
>
> Possible problem: It is the way it is (with int's), because that's the fastest way to
> write it in Java (somebody please prove me wrong! In many, many pieces of Java code,
> we've discovered that the more object-oriented you get, the slower it goes.
> Unfortunately, there's a tradeoff here between maintainability and speed.)
Sometimes clear code have better optimizations.
I do think int's are great and I would like to use them in other
projects ( it will not be easy to convince people, but it's worth to try ).
I spent days trying to understand StringPool/SymbolCache.
If you hide the int[] behind a simple interface you may have
a reasonable compromise - maybe you loose 2% speed because
calling interface method is slower ( probably 0.2 % ), but
then you may have many other optimizations because the
code is cleaner.
And using interfaces will allow multiple implementations, tuned
for various JITs ( or hotspots)
( the reallocation using int[][] is another great idea, it would
be bad to lose it because it's so hard to understand it)
Costin
Re: [Xerces2] What is CORE?
Posted by Mike Pogue <mp...@apache.org>.
Actually, allocating memory in big chunks like this is fairly efficient in Java, and it
eliminates a huge amount of object creation time. gc is also very much reduced (so, it
doesn't matter whether you use generational or some other style of gc -- the technique
works well for all JVM's).
I agree that if Hotspot were everywhere, the design point would be different.
I've asked the Sun folks for info on how to write a program that runs efficiently using
ALL JIT's (not just Hotspot). I figured that if anybody knew, they would....(but I could
be wrong).
Mike
Paulo Gaspar wrote:
>
> That is a Java problem... that tends to get fixed.
>
> If you used C, C++ or even Turbo Pascal/Delphi, you know that dynamic
> memory allocation does not have to be so expensive. I think that had
> quite an improvement with the new memory allocation techniques used in
> the 1.3 JDK's VM.
>
> Short term memory allocation (that is what we are usually talking about
> when we talk about DOM trees) got cheaper. Let's develop for the future
> VMs and not to the past, because that gets cheaper too.
>
> Anyway, due to Java (no pointer) limitations, I can only imagine that
> making your own memory allocation in arrays imposes more overhead when
> manipulating those structures than the same technique would impose in C
> (for instance). So, this hand coded memory allocation techniques will
> be more expensive than in C and the new memory allocation in 1.3's VM
> will be quite similar to C's memory allocation cost.
>
> The obvious: probably this hand made memory allocation will be even
> less profitable in the 1.3's VM than it would be in C. (And there is
> not so much situations where one builds a sub-allocator in C.)
>
> Now, I already red complains about the new VM slowing down the current
> parser and people being skeptical about this VM out of that. Well,
> before making your judgments, go to SUN's site and check on the
> performance related notes they have there.
> (http://java.sun.com/products/hotspot/1.0/Q+A.html)
>
> One of the issues they point is that at startup the Hotspot compiler
> tends to cause some overhead due to compilation work. It only speeds up
> when the marked "hotspots" get compiled. (They try to use idle time to
> compile but it still tends to cause noticeable overhead.)
>
> Since the current Xerces parser as its own memory allocation scheme, it
> does not even benefit from the other performance gain in this VM - the
> memory allocation.
>
> When evaluating performance, consider running the test application for
> a longer period in order to have the "hotspots" compiled. Most of the
> applications where the parser will be used will behave like that anyway.
>
> Of course that if your applications only run for a very short time, you
> will not have so much profit from the Hotspot technique. Still, memory
> allocation will still make a difference and it is a natural next step in
> the VM evolution to have some of those "Hotspots" permanently compiled.
>
> Conclusion: even if the hand made memory allocators are still a bit
> faster with the 1.3 JDK's VM (which I doubt) the difference will
> probably be so small that it will not pay for the messy code.
>
> Anyway, before evaluating this new VM performance, read SUN's notes on
> that subject (http://java.sun.com/products/hotspot/1.0/Q+A.html).
>
> If you think that Hotspot will mot be ported everywhere, this is are
> some news:
>
> Java HotSpot Server VM 2.0 source will be available shortly - (this
> notice as of 7/13/00). Please check back for information regarding
> download link.
>
> Java HotSpot Client VM source will be available as part of the Java 2
> Platform, Standard Edition v 1.3 SDK - (this notice as of 7/13/00).
> Please check back for information regarding download link.
>
> (at http://www.javasoft.com/products/hotspot/)
>
> And have fun,
> Paulo Gaspar
>
> > -----Original Message-----
> > From: Mike Pogue [mailto:mpogue@apache.org]
> > Sent: Tuesday, July 18, 2000 01:46
> > To: xerces-j-dev@xml.apache.org
> > Subject: Re: [Xerces2] What is CORE?
> >
> >
> > Yep, as long as performance is maintained, I think this could be
> > a Good Thing.
> >
> > Possible problem: It is the way it is (with int's), because
> > that's the fastest way to
> > write it in Java (somebody please prove me wrong! In many, many
> > pieces of Java code,
> > we've discovered that the more object-oriented you get, the
> > slower it goes.
> > Unfortunately, there's a tradeoff here between maintainability and speed.)
> >
> > Mike
> >
> > James Duncan Davidson wrote:
> > >
> > > on 7/15/00 2:49 PM, Ted Leung at twleung@sauria.com wrote:
> > >
> > > >> From some of the other discussions we've been having, it
> > seems like the
> > > > maintainability
> > > > complaints might be addressed by modifying this API away from ints and
> > > > toward
> > > > StringHolders, StringRecyclers, or StringTrashCompactors.
> > Unfortunately,
> > > > that's not
> > > > all that revolutionary.
> > >
> > > Well, it is in the fact that the core Xerces 1.0 codebase shouldn't be
> > > subjected to that impactful a code change (from performance to code
> > > stability).
> > >
> > > Maybe if a rewrite were attempted on that code in a clear way
> > with Strings,
> > > (or whatever) that was clear code, it would be a good thing.
> > >
> > > .duncan
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
RE: [Xerces2] What is CORE?
Posted by Paulo Gaspar <pa...@krankikom.de>.
That is a Java problem... that tends to get fixed.
If you used C, C++ or even Turbo Pascal/Delphi, you know that dynamic
memory allocation does not have to be so expensive. I think that had
quite an improvement with the new memory allocation techniques used in
the 1.3 JDK's VM.
Short term memory allocation (that is what we are usually talking about
when we talk about DOM trees) got cheaper. Let's develop for the future
VMs and not to the past, because that gets cheaper too.
Anyway, due to Java (no pointer) limitations, I can only imagine that
making your own memory allocation in arrays imposes more overhead when
manipulating those structures than the same technique would impose in C
(for instance). So, this hand coded memory allocation techniques will
be more expensive than in C and the new memory allocation in 1.3's VM
will be quite similar to C's memory allocation cost.
The obvious: probably this hand made memory allocation will be even
less profitable in the 1.3's VM than it would be in C. (And there is
not so much situations where one builds a sub-allocator in C.)
Now, I already red complains about the new VM slowing down the current
parser and people being skeptical about this VM out of that. Well,
before making your judgments, go to SUN's site and check on the
performance related notes they have there.
(http://java.sun.com/products/hotspot/1.0/Q+A.html)
One of the issues they point is that at startup the Hotspot compiler
tends to cause some overhead due to compilation work. It only speeds up
when the marked "hotspots" get compiled. (They try to use idle time to
compile but it still tends to cause noticeable overhead.)
Since the current Xerces parser as its own memory allocation scheme, it
does not even benefit from the other performance gain in this VM - the
memory allocation.
When evaluating performance, consider running the test application for
a longer period in order to have the "hotspots" compiled. Most of the
applications where the parser will be used will behave like that anyway.
Of course that if your applications only run for a very short time, you
will not have so much profit from the Hotspot technique. Still, memory
allocation will still make a difference and it is a natural next step in
the VM evolution to have some of those "Hotspots" permanently compiled.
Conclusion: even if the hand made memory allocators are still a bit
faster with the 1.3 JDK's VM (which I doubt) the difference will
probably be so small that it will not pay for the messy code.
Anyway, before evaluating this new VM performance, read SUN's notes on
that subject (http://java.sun.com/products/hotspot/1.0/Q+A.html).
If you think that Hotspot will mot be ported everywhere, this is are
some news:
Java HotSpot Server VM 2.0 source will be available shortly - (this
notice as of 7/13/00). Please check back for information regarding
download link.
Java HotSpot Client VM source will be available as part of the Java 2
Platform, Standard Edition v 1.3 SDK - (this notice as of 7/13/00).
Please check back for information regarding download link.
(at http://www.javasoft.com/products/hotspot/)
And have fun,
Paulo Gaspar
> -----Original Message-----
> From: Mike Pogue [mailto:mpogue@apache.org]
> Sent: Tuesday, July 18, 2000 01:46
> To: xerces-j-dev@xml.apache.org
> Subject: Re: [Xerces2] What is CORE?
>
>
> Yep, as long as performance is maintained, I think this could be
> a Good Thing.
>
> Possible problem: It is the way it is (with int's), because
> that's the fastest way to
> write it in Java (somebody please prove me wrong! In many, many
> pieces of Java code,
> we've discovered that the more object-oriented you get, the
> slower it goes.
> Unfortunately, there's a tradeoff here between maintainability and speed.)
>
> Mike
>
> James Duncan Davidson wrote:
> >
> > on 7/15/00 2:49 PM, Ted Leung at twleung@sauria.com wrote:
> >
> > >> From some of the other discussions we've been having, it
> seems like the
> > > maintainability
> > > complaints might be addressed by modifying this API away from ints and
> > > toward
> > > StringHolders, StringRecyclers, or StringTrashCompactors.
> Unfortunately,
> > > that's not
> > > all that revolutionary.
> >
> > Well, it is in the fact that the core Xerces 1.0 codebase shouldn't be
> > subjected to that impactful a code change (from performance to code
> > stability).
> >
> > Maybe if a rewrite were attempted on that code in a clear way
> with Strings,
> > (or whatever) that was clear code, it would be a good thing.
> >
> > .duncan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
Re: [Xerces2] What is CORE?
Posted by Mike Pogue <mp...@apache.org>.
Yep, as long as performance is maintained, I think this could be a Good Thing.
Possible problem: It is the way it is (with int's), because that's the fastest way to
write it in Java (somebody please prove me wrong! In many, many pieces of Java code,
we've discovered that the more object-oriented you get, the slower it goes.
Unfortunately, there's a tradeoff here between maintainability and speed.)
Mike
James Duncan Davidson wrote:
>
> on 7/15/00 2:49 PM, Ted Leung at twleung@sauria.com wrote:
>
> >> From some of the other discussions we've been having, it seems like the
> > maintainability
> > complaints might be addressed by modifying this API away from ints and
> > toward
> > StringHolders, StringRecyclers, or StringTrashCompactors. Unfortunately,
> > that's not
> > all that revolutionary.
>
> Well, it is in the fact that the core Xerces 1.0 codebase shouldn't be
> subjected to that impactful a code change (from performance to code
> stability).
>
> Maybe if a rewrite were attempted on that code in a clear way with Strings,
> (or whatever) that was clear code, it would be a good thing.
>
> .duncan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [Xerces2] What is CORE?
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 7/15/00 2:49 PM, Ted Leung at twleung@sauria.com wrote:
>> From some of the other discussions we've been having, it seems like the
> maintainability
> complaints might be addressed by modifying this API away from ints and
> toward
> StringHolders, StringRecyclers, or StringTrashCompactors. Unfortunately,
> that's not
> all that revolutionary.
Well, it is in the fact that the core Xerces 1.0 codebase shouldn't be
subjected to that impactful a code change (from performance to code
stability).
Maybe if a rewrite were attempted on that code in a clear way with Strings,
(or whatever) that was clear code, it would be a good thing.
.duncan
Re: [Xerces2] What is CORE?
Posted by Ted Leung <tw...@sauria.com>.
----- Original Message -----
From: "James Duncan Davidson" <ja...@eng.sun.com>
To: <xe...@xml.apache.org>
Sent: Friday, July 14, 2000 9:31 PM
Subject: Re: [Xerces2] What is CORE?
> on 7/14/00 4:08 PM, Arved Sandstrom at Arved_37@chebucto.ns.ca wrote:
>
> > I think the production of a tree is definitely one notch higher up in
> > processing than SAX-style production of events. I think the actual
"event
> > core" need not be SAX - witness expat, which is very successful.
>
> Right.. And it need not be Event -- it could be pull. In which case a
little
> thread can sit in the SAXEventProducer and pull next chunk and fire SAX
> events based on that.
>
> > I see a compact, fast parser that produces raw Xerces2 events. A SAX2
API
> > builds on that. An integral Xerces2 DOM API uses Xerces2 events; it
would
> > also be possible for outside DOM implementations to use the SAX API.
>
The Xerces1 parser has an internal API that gets turned into SAX events or
into
a DOM (in the case of the deferred DOM). The only problem with that API is
that is uses ints, which has been widely cited as a problem. I wonder if
this is
really a problem or whether it's just that the documentation in the code is
horrible.
Re: [Xerces2] What is CORE?
Posted by Ted Leung <tw...@sauria.com>.
In the current Xerces, the "push" parser is really a loop
that calls the private pull parser API.
It doesn't hurt performance very much in this case.
Ted
----- Original Message -----
From: "Paulo Gaspar" <pa...@krankikom.de>
To: <xe...@xml.apache.org>
Sent: Saturday, July 15, 2000 6:41 AM
Subject: RE: [Xerces2] What is CORE?
> In the descriptions I have been reading about the "pull" approach, I
> still get the feeling that it can be nice for some applications when
> saving resources at some performance cost.
>
> Hardly a generic solution.
>
> For most of my applications I do NOT mind that much the memory but I
> DO mind a lot the speed.
>
>
> Notice that I am questioning and not condemning.
>
>
> Have fun,
> Paulo Gaspar
>
> > -----Original Message-----
> > From: James Duncan Davidson [mailto:james.davidson@eng.sun.com]
> > Sent: Saturday, July 15, 2000 06:31
> > To: xerces-j-dev@xml.apache.org
> > Subject: Re: [Xerces2] What is CORE?
> >
> >
> > on 7/14/00 4:08 PM, Arved Sandstrom at Arved_37@chebucto.ns.ca wrote:
> >
> > > I think the production of a tree is definitely one notch higher up in
> > > processing than SAX-style production of events. I think the
> > actual "event
> > > core" need not be SAX - witness expat, which is very successful.
> >
> > Right.. And it need not be Event -- it could be pull. In which
> > case a little
> > thread can sit in the SAXEventProducer and pull next chunk and fire SAX
> > events based on that.
> >
> > > I see a compact, fast parser that produces raw Xerces2 events.
> > A SAX2 API
> > > builds on that. An integral Xerces2 DOM API uses Xerces2
> > events; it would
> > > also be possible for outside DOM implementations to use the SAX API.
> >
> > Right. And the JDOM impl would probably be best served by using
> > straight X2
> > events rather than go through some intermediary. The idea of having a
tree
> > model inside that serves both DOM and JDOM seems, well, hard to do --
they
> > have differing centers. Maybe it could happen, but I wouldn't try to
force
> > it for sure.
> >
> > > I think these arguments are not out of line with a
> > design-oriented approach
> > > that includes performance as a requirement. As before, I
> > entreat folks to
> > > actually define "performance".
> >
> > Fast enough to not notice that a parse happened for most data (10 lines
to
> > 10K). :)
> >
> > To expand on that, when I have Ant read it's data from build.xml, I
> > shouldn't notice. If I send a bit of form encoded XML data to a
> > server, and
> > then get some back, it shouldn't be appreciable considering the
connection
> > cost.
> >
> > Hows that for out there and non-quantifiable? :)
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>
>
RE: [Xerces2] What is CORE?
Posted by Paulo Gaspar <pa...@krankikom.de>.
In the descriptions I have been reading about the "pull" approach, I
still get the feeling that it can be nice for some applications when
saving resources at some performance cost.
Hardly a generic solution.
For most of my applications I do NOT mind that much the memory but I
DO mind a lot the speed.
Notice that I am questioning and not condemning.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: James Duncan Davidson [mailto:james.davidson@eng.sun.com]
> Sent: Saturday, July 15, 2000 06:31
> To: xerces-j-dev@xml.apache.org
> Subject: Re: [Xerces2] What is CORE?
>
>
> on 7/14/00 4:08 PM, Arved Sandstrom at Arved_37@chebucto.ns.ca wrote:
>
> > I think the production of a tree is definitely one notch higher up in
> > processing than SAX-style production of events. I think the
> actual "event
> > core" need not be SAX - witness expat, which is very successful.
>
> Right.. And it need not be Event -- it could be pull. In which
> case a little
> thread can sit in the SAXEventProducer and pull next chunk and fire SAX
> events based on that.
>
> > I see a compact, fast parser that produces raw Xerces2 events.
> A SAX2 API
> > builds on that. An integral Xerces2 DOM API uses Xerces2
> events; it would
> > also be possible for outside DOM implementations to use the SAX API.
>
> Right. And the JDOM impl would probably be best served by using
> straight X2
> events rather than go through some intermediary. The idea of having a tree
> model inside that serves both DOM and JDOM seems, well, hard to do -- they
> have differing centers. Maybe it could happen, but I wouldn't try to force
> it for sure.
>
> > I think these arguments are not out of line with a
> design-oriented approach
> > that includes performance as a requirement. As before, I
> entreat folks to
> > actually define "performance".
>
> Fast enough to not notice that a parse happened for most data (10 lines to
> 10K). :)
>
> To expand on that, when I have Ant read it's data from build.xml, I
> shouldn't notice. If I send a bit of form encoded XML data to a
> server, and
> then get some back, it shouldn't be appreciable considering the connection
> cost.
>
> Hows that for out there and non-quantifiable? :)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
Re: [Xerces2] What is CORE?
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 7/14/00 4:08 PM, Arved Sandstrom at Arved_37@chebucto.ns.ca wrote:
> I think the production of a tree is definitely one notch higher up in
> processing than SAX-style production of events. I think the actual "event
> core" need not be SAX - witness expat, which is very successful.
Right.. And it need not be Event -- it could be pull. In which case a little
thread can sit in the SAXEventProducer and pull next chunk and fire SAX
events based on that.
> I see a compact, fast parser that produces raw Xerces2 events. A SAX2 API
> builds on that. An integral Xerces2 DOM API uses Xerces2 events; it would
> also be possible for outside DOM implementations to use the SAX API.
Right. And the JDOM impl would probably be best served by using straight X2
events rather than go through some intermediary. The idea of having a tree
model inside that serves both DOM and JDOM seems, well, hard to do -- they
have differing centers. Maybe it could happen, but I wouldn't try to force
it for sure.
> I think these arguments are not out of line with a design-oriented approach
> that includes performance as a requirement. As before, I entreat folks to
> actually define "performance".
Fast enough to not notice that a parse happened for most data (10 lines to
10K). :)
To expand on that, when I have Ant read it's data from build.xml, I
shouldn't notice. If I send a bit of form encoded XML data to a server, and
then get some back, it shouldn't be appreciable considering the connection
cost.
Hows that for out there and non-quantifiable? :)
Re: [Xerces2] What is CORE?
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 04:52 PM 7/14/00 -0500, Brett McLaughlin wrote:
>
>Ed Staub wrote:
>>
>> I think I've detected an inconsistency in the current consensus on what a
>> core would look like. Basically: is there a tree in it or not?
>>
>> I think that folks using event-driven API's like SAX2 would not want to be
>> burdened with the overhead of creating a tree.
>>
>> On the other hand, there's a lot of reusability to be provided by a common
>> layer under DOM, JDOM, XPath, et al. (Brett, in response to
>> http://xml-archive.webweaving.org/xml-archive-general/2274.html, I'm
>> thinking option #3.)
>>
>> So instead of seeing
>>
>> DOM SAX2 JDOM
>> | | |
>> ------------
>> |
>> CORE
>>
>> I see two levels of "core", an event core underneath a tree core.
>> Perhaps something like the Xalan might be used.
>>
>> other
>> tree
>> DOM JDOM users
>> | | |
>> ------------
>> |
>> | other
>> TREE event
>> SAX2 CORE listeners
>> | | |
>> -------------
>> |
>> EVENT
>> CORE
>>
>> This may have been really obvious to everyone.
>> If so, sorry to belabor it.
>
>No, I think we need to be very clear, even to the point of obvious, or
>someone, somewhere, is going to be upset because "they thought X was
>going to happen instead of Y". I agree with your diagram, although I'm
>not sure how the TREE CORE can be done - DOM and JDOM are actually quite
>different beasts, and we'll have to think hard on it. I'm all for it if
>it can be done without /either/ API suffering. But that's off in the
>distance - first, we need to start the EVENT CORE design in detail.
>
>-Brett
>
>> -Ed
>>
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc.
>1200 Pacific Avenue, Suite 300
>Santa Cruz, CA 95060 USA
>http://www.lutris.com
>http://www.enhydra.org
>
>---------------------------------------------------------------------
Hi, Ed, Brett, others
I think the production of a tree is definitely one notch higher up in
processing than SAX-style production of events. I think the actual "event
core" need not be SAX - witness expat, which is very successful.
I see a compact, fast parser that produces raw Xerces2 events. A SAX2 API
builds on that. An integral Xerces2 DOM API uses Xerces2 events; it would
also be possible for outside DOM implementations to use the SAX API.
I think these arguments are not out of line with a design-oriented approach
that includes performance as a requirement. As before, I entreat folks to
actually define "performance".
Arved Sandstrom
Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"
Re: [Xerces2] What is CORE?
Posted by Brett McLaughlin <br...@lutris.com>.
Ed Staub wrote:
>
> I think I've detected an inconsistency in the current consensus on what a
> core would look like. Basically: is there a tree in it or not?
>
> I think that folks using event-driven API's like SAX2 would not want to be
> burdened with the overhead of creating a tree.
>
> On the other hand, there's a lot of reusability to be provided by a common
> layer under DOM, JDOM, XPath, et al. (Brett, in response to
> http://xml-archive.webweaving.org/xml-archive-general/2274.html, I'm
> thinking option #3.)
>
> So instead of seeing
>
> DOM SAX2 JDOM
> | | |
> ------------
> |
> CORE
>
> I see two levels of "core", an event core underneath a tree core.
> Perhaps something like the Xalan might be used.
>
> other
> tree
> DOM JDOM users
> | | |
> ------------
> |
> | other
> TREE event
> SAX2 CORE listeners
> | | |
> -------------
> |
> EVENT
> CORE
>
> This may have been really obvious to everyone.
> If so, sorry to belabor it.
No, I think we need to be very clear, even to the point of obvious, or
someone, somewhere, is going to be upset because "they thought X was
going to happen instead of Y". I agree with your diagram, although I'm
not sure how the TREE CORE can be done - DOM and JDOM are actually quite
different beasts, and we'll have to think hard on it. I'm all for it if
it can be done without /either/ API suffering. But that's off in the
distance - first, we need to start the EVENT CORE design in detail.
-Brett
>
> -Ed
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
--
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc.
1200 Pacific Avenue, Suite 300
Santa Cruz, CA 95060 USA
http://www.lutris.com
http://www.enhydra.org