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 James Duncan Davidson <du...@x180.com> on 2000/08/01 03:44:03 UTC
Re: XRI requirements update
on 7/29/00 3:40 PM, Ted Leung at twleung@sauria.com wrote:
> +1. I think that we need another name for the API between the core and the
> API adapters. Calling it the internal API just seems to get too many people
> hacked off. How about the "xerces native API". Almost as bad as internal, but
> maybe it will gross enough of us out so that someone will produce a better
> name.
Ok.. Xerces Consumer API and Xerces Validator API. :)
>> Understand. Is having the pull in the core critical, or just the ability to
>> pull -- ie, could the pull sit on top of a recursive-descent or no? (pardon
>> me if it sounds ass stupid, just exploring).
>>
> I prefer to have it in the core, because I may want to put a pull model API
> adapter on top of the core.
>
> As far as recursive decent goes, I think that this is not the time to be
> discussing how the parser will be implemented.
Sure. But just checking to make sure of the wheres were of whats possible
given a set of requirements. So -- at the requirements level, the parser has
to support pull model. We'll talk about how to do so later.
> I'm not going to
> participate in the design of a parser which doesn't satisfy my requirements,
> so I'm not paying attention to the design until requirements are done.
Fair enough as I have the same feelings. :)
CONFLICTS:
> 2 vs 24
I'd be ok to change 2 to "the parser should have a minimal memory footprint"
or even "the parser should have a competitive memory footprint" (competitive
against the other Java based parsers out there)
> 2 vs 10
Don't see this as a hard conflict, but if folks go for the softening on 2,
would this take care of this for you?
> 5 vs 24
Order them. 5 comes before 24. Or, add to 24 something like "The parser
should provide best-of-breed performance across all VMs. Such performance
shall not come at the expense of 5."
> 10 vs 23
Hows the conflict in this? Modularity helps turn off features...
> 10 vs 36
I see 36 as something that is outside of the scope of general purpose parser
work. If you are code generating parsers based on Schemas (or even
generating byte code direct to a VM following a schema) you are necessarily
creating something that isn't a general purpose parser any more and you get
the advantages of shedding *everything* not needed. It's a really cool idea,
but it's a different beast than what we are talking about doing as far as a
parser that can take any kind of XML content and validate it against
whatever. imho anyway.
.duncan
Re: Newbie question about Xerces' SAX implementation
Posted by Andy Clark <an...@apache.org>.
Yves Arrouye wrote:
> but in endElement I get
>
> name rnef:update
> qName rnef:update
This was a bug and I believe it's already been fixed. What version
of Xerces are you using? Have you tried 1.1.3?
--
Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org
Newbie question about Xerces' SAX implementation
Posted by Yves Arrouye <yv...@realnames.com>.
Please pardon me if I'm asking a stupid question, but I couldn't access the
archives to see if somebody did before me :)
I was playing with the SAX implementation in Xerces, and had an XML file
like:
<?xml version="1.0" ?>
<rnef:update xmlns:rnef="urn:nobody-uses-urns-correctly:schema">
<sometag>
...
</sometag>
</rnef:update>
Now, if I look at what I have for name and qName in startElement on the
rnef:update tag, I get
name update
qName rnef:update
but in endElement I get
name rnef:update
qName rnef:update
How come I don't get update at the end of the element too? Is it to be
expected, and why?
Thanks!
YA
Re: XRI requirements update
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 8/2/00 5:08 PM, Ed Staub at estaub@mediaone.net wrote:
> External API - for general users
Almost like "supported standard APIs" as these are SAX, DOM, JDOM, etc. At
least until somebody here invents a new API that should be standardized.
> Published Internal API - for developers of other parser API's, etc.
Yep.
> Internals - not an API at all; for use by Xerces developers
Yep.
RE: XRI requirements update
Posted by Ed Staub <es...@mediaone.net>.
I was thinking there'd be three sets of doc:
External API - for general users
Published Internal API - for developers of other parser API's, etc.
Internals - not an API at all; for use by Xerces developers
-Ed Staub
-----Original Message-----
From: Andy Clark [mailto:andyc@apache.org]
Sent: Wednesday, August 02, 2000 7:05 PM
To: xerces-j-dev@xml.apache.org
Subject: Re: XRI requirements update
James Duncan Davidson wrote:
> Hrm. How about Xerces Published Internal API (vs. Unpublished)
> for which we'd go ahead and make Javadocs available somewhere
> (vs. the unpublished ones which we wouldn't)?
Maybe we don't even need to name the internal API. I would be
in favor of producing two sets of JavaDoc output: one for users
and one for developers. Only the stuff documented in the
developer's JavaDoc would be the "internal" API.
--
Andy Clark * IBM, JTC - Silicon Valley * andyc@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: XRI requirements update
Posted by Andy Clark <an...@apache.org>.
James Duncan Davidson wrote:
> Hrm. How about Xerces Published Internal API (vs. Unpublished)
> for which we'd go ahead and make Javadocs available somewhere
> (vs. the unpublished ones which we wouldn't)?
Maybe we don't even need to name the internal API. I would be
in favor of producing two sets of JavaDoc output: one for users
and one for developers. Only the stuff documented in the
developer's JavaDoc would be the "internal" API.
--
Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org
Re: XRI requirements update
Posted by James Duncan Davidson <du...@x180.com>.
on 8/1/00 5:53 PM, Andy Clark at andyc@apache.org wrote:
> James Duncan Davidson wrote:
>> Ok.. Xerces Consumer API and Xerces Validator API. :)
>
> Yuck! Just kidding...
Didn't say I'd do any better than the previous suggestion.. :)
> Actually I'm wondering if we even need to
> make a differentiation between the consumer and validator APIs.
> To me, the validator is just another consumer of the document
> events in the pipeline. Oh, how about "Xerces Pipeline API"?
> Nah, I don't like that either.
Hrm. How about Xerces Published Internal API (vs. Unpublished) for which
we'd go ahead and make Javadocs available somewhere (vs. the unpublished
ones which we wouldn't)?
.duncan
Re: XRI requirements update
Posted by Andy Clark <an...@apache.org>.
James Duncan Davidson wrote:
> Ok.. Xerces Consumer API and Xerces Validator API. :)
Yuck! Just kidding... Actually I'm wondering if we even need to
make a differentiation between the consumer and validator APIs.
To me, the validator is just another consumer of the document
events in the pipeline. Oh, how about "Xerces Pipeline API"?
Nah, I don't like that either.
--
Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org
Re: XRI requirements update
Posted by Ted Leung <tw...@sauria.com>.
----- Original Message -----
From: "James Duncan Davidson" <du...@x180.com>
To: <xe...@xml.apache.org>
Sent: Monday, July 31, 2000 6:44 PM
Subject: Re: XRI requirements update
> on 7/29/00 3:40 PM, Ted Leung at twleung@sauria.com wrote:
>
> CONFLICTS:
>
> > 2 vs 24
>
> I'd be ok to change 2 to "the parser should have a minimal memory
footprint"
> or even "the parser should have a competitive memory footprint"
(competitive
> against the other Java based parsers out there)
>
> > 2 vs 10
>
> Don't see this as a hard conflict, but if folks go for the softening on 2,
> would this take care of this for you?
Yes
> > 5 vs 24
>
> Order them. 5 comes before 24. Or, add to 24 something like "The parser
> should provide best-of-breed performance across all VMs. Such performance
> shall not come at the expense of 5."
Yes
Witness the recent loud discussion about scrapping the Java efforts because
they
are too slow. The gentleman has a point, too.
> > 10 vs 23
>
> Hows the conflict in this? Modularity helps turn off features...
In order to accomplish 23, you may do things that reduce 10. Everyone in
the discussions so far has assumed that we didn't think of many of these
issues.
We did. The dial was turn all the way to the max on performance.
> > 10 vs 36
>
> I see 36 as something that is outside of the scope of general purpose
parser
> work. If you are code generating parsers based on Schemas (or even
> generating byte code direct to a VM following a schema) you are
necessarily
> creating something that isn't a general purpose parser any more and you
get
> the advantages of shedding *everything* not needed. It's a really cool
idea,
> but it's a different beast than what we are talking about doing as far as
a
> parser that can take any kind of XML content and validate it against
> whatever. imho anyway.
I say remove 36.
> .duncan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>
>