You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xml.apache.org by Ed Staub <es...@mediaone.net> on 2000/07/12 06:03:53 UTC
XRI requirements
Here's a quick copy-and-paste list of the proposed
XRI/Spinnaker/Xerces-2/X2/XRay requirements which have been discussed by
various people over the last few days. (Ok, I just threw in "X2" and
"XRay"!;) I did some light editing for clarity. I probably missed a few!
If folks would like me to do more with the proposed requirements list,
please let me know and I'll propose some procedures and (better!)
formatting. But I suspect that it may be desirable to have a more
well-known and experienced person recording the proposed requirements. It's
clearly a sensitive area where a person widely believed to be impartial
would be very valuable.
Regardless... what's missing?
-Ed Staub
FEATURES and STANDARDS COMPLIANCE
---------------------------------
Validating XML 1.0 support
Namespace support
SAX2 support
DOM Level 2 support
XML Schema support
XPath support
XInclude support
Write validation of a DOM tree or revalidation
Grammar access for both DTD and Schema.
Document-order indexes or API as a DOM extension.
[optional] isWhite() method as a DOM extensions (pure telling of
whether or not the text contains non-whitespace), for performance reasons.
Serialization support, as is currently in Assaf's classes.
PERFORMANCE
-----------
No significant speed penalty for unused features, notably validation.
Best-of-breed performance across all JIT's (not just Hotspot).
Grammar caching, pre-compiled grammar can be cached to validate instance
documents over and over again without re-reading the DTD and Schema file or
even compile it.
A configurable parser, in line with the requirements of Modularity and
pluggable Validator somebody posted before. Not only should the validator
be pluggable, but also if there is a need for a parser without validation at
all, there should be some parser configuration which is really lightweight
and just scans, checks well-formedness, and generates SAX2 events. Or even
fancier, a brand new functional module can be plugged in BETWEEN components
as long as it implements certain interfaces. [Eric Ye]
Mid to upper range validation performance across all JVMs.
Read-only, memory conservative, high performance DOM subset (for Xalan et
al)
Parsing in chunks [Scott Boag]
A reasonable core (fast!) upon which to layer JDOM [Brett M.]
Some sort of weak reference, where nodes could be released if not
referenced, and then rebuilt if requested. For performance and memory
footprint.
Some sort of way to tell if a SAX char buffer is going to be
overwritten, so data doesn't have to be copied until this occurs.
Small core footprint for standalone, compiled stylesheet capability, for
use on small devices. This would need to include the Serializer. I'm not
sure if this should really be a separate micro-parser?
Smallest possible size. This means small distribution size (JAR
file) and small memory footprint.
OTHER QUALITIES
----------------
Clarity of design and code sufficient to encourage wide participation.
Code should always be readable and maintainable.
Design portable to C++ (or elsewhere)
More documentation on the Apache web site not only for users but for
DEVELOPERs.
Testcases for both conformance and benchmarking.
===============================
NOMINAL NON-REQUIREMENTS:
Someone stated, without dissent (yet!), that these do not need to be
supported:
SAX 1 support
RE: XRI requirements - and overdefensiveness in
OpenSourceLand...
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 07:21 AM 7/17/00 +0200, Paulo Gaspar wrote:
>
>> Point being, we have not necessarily adequately captured culture
>> and respect
>> when we employ English. I'm thinking that the broad use of English, which
>> exemplifies current American mores, is maybe always not so good. Maybe we
>> should respect attempts to use native languages. I am personally
>> capable of
>> reading French and German, and responding in kind (sometimes
>> brokenly), and
>> of course I can do Estonian. :-) Portuguese is beyond me. :-)
>
>Estonian is beyond me.
>=:o)
It should be beyond most reasonable people. We have 14 verb cases, and
pronounciation that defies belief. :-)
We also don't need pronouns. We can compress sentences into one word. :-)
And we have some nice umlauts: try pronouncing "o~un" properly, or "po"an",
or "raukusno~drameelsus". :-)
Actually, Italian won a prize back in the '30's for being the world's most
mellifluous language. Estonian was second.
>I think English is still the easier one. I have learned rudiments of German
>and Dutch but these are so difficult for a latin. But even being a latin,
>English was much easier to learn for me than French.
>
>As many Portuguese, I also understand Spanish and Italien. Still, nothing is
>so easy learning to speak without too much mistakes as English.
>(Although impossible to speak like a native.)
Don't even try understanding English speaken in rural areas. Can't comment
on England, but if you listen to Newfoundland speakers, Maine speakers, or
speakers from a number of different Nova Scotian areas, you can't understand
what they are saying. _I_ have lived in Nova Scotia practically all my life,
but I still can't understand some of these people. :-)
Your English is good. Despite that, I'm surprised to hear you say it's easy
to use. Heavy media exposure, maybe?
Arved
Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"
RE: XRI requirements - and overdefensiveness in OpenSourceLand...
Posted by Paulo Gaspar <pa...@krankikom.de>.
> -----Original Message-----
> From: Arved Sandstrom [mailto:Arved_37@chebucto.ns.ca]
> Sent: Sunday, July 16, 2000 06:32
>
> Let's not dismiss personal respect and professional courtesy. Maybe the
> reason I don't work at M$ is perhaps because if someone told me
> that what I
> just said "was stupid f****g BS", that there would be immediate physical
> repercussions.
I never heard that they talk that way about people. The sentence "that is
the stupidest f***king thing I ever heard!" was already mentioned in the
news several times as being one of BG favourites and generally used at MS.
Anyway, the idea is NOT to insult someone but too tell what you think
about something without wasting too much energy being polite.
I must say that I do not find Apache lists to be that bad. I guess I am
just traumatized from what I sometimes happens in other mailling lists.
> The requirement, I think, is that we do not cultivate deliberate
> abrasiveness. What I like about Stefano is that he may be "in
> your face" but I don't think he does it on purpose. Plus I think he
> respects everyone.
I like the "in your face" style. You know better what to expect when you
deal with such person.
> >And I do not even think that his style is very Italian.
> >Italian style is similar to very Portuguese very French or very
> >British. It is a "I am THE MAN and I am always right" style.
> >(By the way, I am Portuguese.)
>
> OK, you might be right. :-) Still, you don't know Estonians. We
> are pretty
> formal. When I write my _sisters_ I use uppercase "Sina", which is like
> German "Sie" when talking to an individual. When I talk or write to
> strangers in Estonian, I am more formal still: it's all third person and
> Herr Doktor kind of stuff. :-)
>
> You don't run across Estonians every day, so to get the right
> picture think
> of rum-running Finns with a strong exposure to Germans. :-)
Well... I am living in Germany now. But Germany is a big country and they
are not very formal around here. However, I have been in the North and...
Anyway, I think that human kind as an ego thing. We could joke about it
this way:
- Latins, Brits, Americans and other extroverts believe in a loud
campaign about how good they really are;
- Germans (and probably other introverts) believe that being loud is not
cool. Then, they develop a multitude of more subtile techniques to make
the others find out how good they really are.
=;o)
> Point being, we have not necessarily adequately captured culture
> and respect
> when we employ English. I'm thinking that the broad use of English, which
> exemplifies current American mores, is maybe always not so good. Maybe we
> should respect attempts to use native languages. I am personally
> capable of
> reading French and German, and responding in kind (sometimes
> brokenly), and
> of course I can do Estonian. :-) Portuguese is beyond me. :-)
Estonian is beyond me.
=:o)
I think English is still the easier one. I have learned rudiments of German
and Dutch but these are so difficult for a latin. But even being a latin,
English was much easier to learn for me than French.
As many Portuguese, I also understand Spanish and Italien. Still, nothing is
so easy learning to speak without too much mistakes as English.
(Although impossible to speak like a native.)
Have fun,
Paulo Gaspar
RE: XRI requirements - and overdefensiveness in
OpenSourceLand...
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 05:56 PM 7/16/00 +0200, Paulo Gaspar wrote:
>Considering the time I waste with bruised egos (including mine) I got
>a bit ashamed after reading this. I couldn't avoid thinking:
> - "Now, from the time you can spend with mailing lists, look at the
> percent you (me) just waste with ego-and-turf-defending sh*t instead
> of doing something really constructive with it. And, if part of it is
> settling down other's egos and personal sensitivities, a lot is
> because of your (mine) own ego-and-lame-sensitivities crap!"
>
>This is how I feel about it: a bit ashamed.
Let's not dismiss personal respect and professional courtesy. Maybe the
reason I don't work at M$ is perhaps because if someone told me that what I
just said "was stupid f****g BS", that there would be immediate physical
repercussions.
Including if the person was Steve Ballmer. :-)
The requirement, I think, is that we do not cultivate deliberate
abrasiveness. What I like about Stefano is that he may be "in your face" but
I don't think he does it on purpose. Plus I think he respects everyone.
>I also have an ego (big one) and also overreact and also get concerned
>about defending positions I believe just as I am doing now... and
>sometimes (maybe even now) I spend too much time defending those
>positions.
Sure, so do I. I get puffed up with myself from time to time. I think I've
made some pretty decent contributions but sometimes I start thinking of
myself as Don Knuth II. :-) So I need to be taken down a peg or two
occasionally.
>What is too much time defending a position? Is when nothing really
>positive can result for man kind except the fact that they will
>understand that you (the defender) are right and are a great guy!
Point well taken. I got concerned that I was becoming Mr. FOP, and put it
out on the fop-dev mailing list that maybe it's time for a new release
coordinator. Hence allowing me to concentrate on real stuff and not personal
ego.
>The one thing I like most about Stefano is not the work I know from
>him - Cocoon. There is a lot of principles I believe to be wrong there
>(not in architecture/technical stuff, but in working model).
>
>The one thing I like most about Stefano is:
> - his enthusiasm, the way he tries to participate on all he can even if
> only giving his possible 10 cents (in this case his opinion);
> - (and especially) the fact that he as an ego but deals with it, giving
> priority to have the BEST solution working instead of his solution.
> (Never worked with him, but at least he publicly defends this. Not
> everybody dares to do so.)
Agreed. I still want to hear his viewpoint on getting into "voting" - he's
an influential Apache guy, and his "suggestion" carries weight in forums
outside Cocoon and Ant. I don't think it should. That being said, maybe I
have used my position outside FOP also.
>I think that it is a pity if we let "over defensiveness" get in the way
>of creativity, enthusiasm and participation... even if 10 cent
>participation.
Agreed.
>And I do not even think that his style is very Italian.
>Italian style is similar to very Portuguese very French or very
>British. It is a "I am THE MAN and I am always right" style.
>(By the way, I am Portuguese.)
OK, you might be right. :-) Still, you don't know Estonians. We are pretty
formal. When I write my _sisters_ I use uppercase "Sina", which is like
German "Sie" when talking to an individual. When I talk or write to
strangers in Estonian, I am more formal still: it's all third person and
Herr Doktor kind of stuff. :-)
You don't run across Estonians every day, so to get the right picture think
of rum-running Finns with a strong exposure to Germans. :-)
Point being, we have not necessarily adequately captured culture and respect
when we employ English. I'm thinking that the broad use of English, which
exemplifies current American mores, is maybe always not so good. Maybe we
should respect attempts to use native languages. I am personally capable of
reading French and German, and responding in kind (sometimes brokenly), and
of course I can do Estonian. :-) Portuguese is beyond me. :-)
>Paulo Gaspar
>
>
>
>> -----Original Message-----
>> From: Arved Sandstrom [mailto:Arved_37@chebucto.ns.ca]
>> Sent: Sunday, July 16, 2000 01:22
>> To: xerces-j-dev@xml.apache.org
>> Subject: Re: XRI requirements
>>
>>
>> Hi, Ted
>>
>> As I understand it, Stefano's vote doesn't count. He's prolific,
>> and takes
>> an interest in a bunch of stuff, but I agree with you: the rule
>> is that you
>> have "walked the walk and not just talked the talk" before you
>> get proposed
>> as a committer, _within_ the particular Apache project.
>>
>> There is no way that you would want me, for example, as a committer right
>> now, before I deliver some good material.
>>
>> I'd argue that we have been very good about doing this with FOP.
>> There isn't
>> a single person who is actually a committer who hasn't produced
>> some sound
>> contributions before being voted in. We have very solid people as
>> committers.
>>
>> As I understand it, outside people can't vote. I have personally accorded
>> weight to Stefano, but in my opinion he would not actually hold a
>> vote. This
>> has happened in FOP, also. I think we have always waited until there has
>> been a preponderance of FOP committers voting.
>>
>> This sounds like "bust on Stefano" day, and maybe the guy does
>> have a talent
>> of being too honest. :-) I admit to being irritated a few times
>> when he got
>> overly enthusiastic in fop-dev. This is possibly a clash between
>> my Estonian
>> style and his Italian one. :-) That being said, he has definitely
>> established himself as someone who "walks the walk" as well as
>> "talking the
>> talk". So I pay attention to him. :-)
>>
>> Arved
>>
>
>
>---------------------------------------------------------------------
>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: XRI requirements - and overdefensiveness in OpenSourceLand...
Posted by Mike Pogue <mp...@apache.org>.
By tradition (and charter), discussions of adding new committers are generally done on the
mailing list for each subproject. I think it's fine for Stefano to make suggestions for
new committers (he's not a shy person! :-)....
I completely agree that we should keep process overhead low. It's useful when there are
conflicts, but it can get in the way of moving fast...
Mike
James Duncan Davidson wrote:
>
> on 7/16/00 10:18 AM, Arved Sandstrom at Arved_37@chebucto.ns.ca wrote:
>
> > Why don't we get some authoritative pronouncements from Brian?
>
> Brian would probably tell the group to work it out for themsevles. :) But
> that's if he even got a break from his hectic schedule.. :)
>
> The XML PMC is probably the right place to make a "judgement" if a judgement
> has to be made. My opinion is that really anybody who shows interest,
> thought, and ability to work with others is good committer material.
>
> To speak on the direct topic... Does stefano have the right to ask for
> somebody to be a committer -- Sure.. Since he's not a direct Xerces
> committer, it's probably not his place to +1, but he's appropriate for
> making such a suggestion as he is a person who "walks the talk".
>
> The magic "-1" forces enough imho. To take ted's "If so, can I propose
> commit access for Cocoon?" in case -- if anybody on the Cocoon team had a
> reason for not granting access, say Ted nominated a complete outsider who
> had not participated, then they have their -1.. Further more, at least 3 of
> the committers have to say +1.
>
> A note about proceedure. The more we define proceedure, the more things get
> beaurocratic. Proceedure is something that an OSS project should stay away
> from most times. I wrote everything about the procedures listed on
> jakarta.apache.org (based on what I could find that was written down about
> the Apache process) -- and it all got copied virutally verbatium to
> xml.apache.org. And, looking back on it, it's a bit *too* much as it is. :)
> The stuff that was in those original Apache docs (-1/0/+1) contains as much
> as it needed to. Everything else gets worked out at the time it needs to be
> worked out.
>
> The only place where I see it necessary to place proceedure into place is
> those cases where things are limited artificially by the "status quo".
> (I.e. somebody shuts the desire to scratch an itch down because they think
> it's not the right thing to do).
>
> But, that's enough rambling.
>
> .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: XRI requirements - and overdefensiveness in OpenSourceLand...
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 7/16/00 10:18 AM, Arved Sandstrom at Arved_37@chebucto.ns.ca wrote:
> Why don't we get some authoritative pronouncements from Brian?
Brian would probably tell the group to work it out for themsevles. :) But
that's if he even got a break from his hectic schedule.. :)
The XML PMC is probably the right place to make a "judgement" if a judgement
has to be made. My opinion is that really anybody who shows interest,
thought, and ability to work with others is good committer material.
To speak on the direct topic... Does stefano have the right to ask for
somebody to be a committer -- Sure.. Since he's not a direct Xerces
committer, it's probably not his place to +1, but he's appropriate for
making such a suggestion as he is a person who "walks the talk".
The magic "-1" forces enough imho. To take ted's "If so, can I propose
commit access for Cocoon?" in case -- if anybody on the Cocoon team had a
reason for not granting access, say Ted nominated a complete outsider who
had not participated, then they have their -1.. Further more, at least 3 of
the committers have to say +1.
A note about proceedure. The more we define proceedure, the more things get
beaurocratic. Proceedure is something that an OSS project should stay away
from most times. I wrote everything about the procedures listed on
jakarta.apache.org (based on what I could find that was written down about
the Apache process) -- and it all got copied virutally verbatium to
xml.apache.org. And, looking back on it, it's a bit *too* much as it is. :)
The stuff that was in those original Apache docs (-1/0/+1) contains as much
as it needed to. Everything else gets worked out at the time it needs to be
worked out.
The only place where I see it necessary to place proceedure into place is
those cases where things are limited artificially by the "status quo".
(I.e. somebody shuts the desire to scratch an itch down because they think
it's not the right thing to do).
But, that's enough rambling.
.duncan
Re: XRI requirements - and overdefensiveness in
OpenSourceLand...
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 10:48 AM 7/16/00 -0600, N. Sean Timm wrote:
>Paulo Gaspar wrote:
>> Well,
>>
>> Stefano said:
>> > I'm not in the Xerces Dev team, but I would like to propose commit
>> > access for Ed.
>>
>> And Ted answered
>> > As a procedural matter, can you propose commit access for Xerces? If so,
>> > can I propose commit access for Cocoon?
>>
>> And it started looking like too much of turf defending.
>
>I guess I just don't see the problem with anyone proposing commit access.
>The committer guidelines state that another committer or the person desiring
>commit access can request it. Obviously, Stefano has been following this
>list, and he has interacted in a positive way with it. Since he's not a
>committer on the project, he doesn't have a binding vote, but that doesn't
>matter. If one of the committers disagrees, they just have to -1, and the
>proposal won't go through. If a newbie to the list can (according to the
>guidelines) request commit access, I definitely think Stefano should be able
>to propose for someone.
>
>- Sean T.
Why don't we get some authoritative pronouncements from Brian?
Arved
Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"
Re: XRI requirements - and overdefensiveness in OpenSourceLand...
Posted by "N. Sean Timm" <st...@mailgo.com>.
Paulo Gaspar wrote:
> Well,
>
> Stefano said:
> > I'm not in the Xerces Dev team, but I would like to propose commit
> > access for Ed.
>
> And Ted answered
> > As a procedural matter, can you propose commit access for Xerces? If so,
> > can I propose commit access for Cocoon?
>
> And it started looking like too much of turf defending.
I guess I just don't see the problem with anyone proposing commit access.
The committer guidelines state that another committer or the person desiring
commit access can request it. Obviously, Stefano has been following this
list, and he has interacted in a positive way with it. Since he's not a
committer on the project, he doesn't have a binding vote, but that doesn't
matter. If one of the committers disagrees, they just have to -1, and the
proposal won't go through. If a newbie to the list can (according to the
guidelines) request commit access, I definitely think Stefano should be able
to propose for someone.
- Sean T.
RE: XRI requirements - and overdefensiveness in OpenSourceLand...
Posted by Ed Staub <es...@mediaone.net>.
Ted's on vacation, so he won't be speaking for himself for a while.
He talked to me about this last night, so I'm going to attempt to speak for
him in the interim.
He feels that some problems have arisen because folks have been a little
sloppy in following the agreed-upon guidelines for committer entry. [Sorry,
I don't know the history he was referring to, although there was some stuff
over the last week that seemed a bit over the top; search for "Joe Blow".]
He was trying to promote respecting the agreed-upon guidelines for admitting
new committers. It didn't sound like he was being defensive or anything; he
was just trying to be sure he/we were following the guidelines.
I suspect that he'd take back the sentence about proposing Cocoon
committers, just because it can be misread as a turf thing. I think he was
just trying to ask for a guideline clarification by an unfortunate choice of
example.
I'm ok either way, as long as someone will proxy for me when needed if I
don't have committer access.
-Ed
-----Original Message-----
From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
Sent: Sunday, July 16, 2000 11:56 AM
To: xerces-j-dev@xml.apache.org
Subject: RE: XRI requirements - and overdefensiveness in
OpenSourceLand...
Well,
Stefano said:
> I'm not in the Xerces Dev team, but I would like to propose commit
> access for Ed.
And Ted answered
> As a procedural matter, can you propose commit access for Xerces? If so,
> can I propose commit access for Cocoon?
And it started looking like too much of turf defending.
But Ted also added:
> So, +1 on commit access on Ed, and a +1 from Duncan. Stefano also votes
> +1, but I don't know if his vote counts (other than I respect his opinion
> on matters like this).
And Ted started the first sentence with "As a procedural matter"!
I interpret this as "Ted respects Stefano opinion but is concerned with
procedural issues". It sounds like bureaucracy at work at Apache projects
huh?
But also notice that Stefano started is sentence as "I'm not in the Xerces
Dev team, but..." which sounds to me as "I know I have no vote but I still
would like to informally propose...".
But if it is informal, then Ted was over defensive and then Arved got
concerned with that and then so did I.
I do get concerned with this because I see everybody (including me) wasting
time by being over defensive in this and other mailing lists.
Now, maybe there is something here where we could learn from Microsoft best
practices (yes the big Satan!). This is a piece of an e-mail I got from a
Microsoft guy with whom I had a clash in another mailing list:
( Context: our clash got constructive very fast, he implemented something
I and others suggested, I checked on the first version and sent him a
mail suggesting improvements. Since I have a rough style of writing, I
added a note highlighting that even with a rough style it was meant as
constructive criticism.
What follows is part of his reply.
)
"As for the form that suggestions take, you should not worry
about offending me. One thing about Microsoft is that
we tend to take a very confrontational approach with
one another; not a malicious or mean-spirited thing,
it is just that people within MS are quick to tell
each other when they think something is stupid, and
also quick to admit they are wrong when proven wrong.
It seems that nobody has time to worry about phrasing
things in a way to avoid hurting people's feelings,
and people here are mostly thick-skinned enough to
take all sorts of criticism without being offended.
I really think that style of communication works great,
but we always have to remember not to do that with
customers :-) So anyway, usually if you tell someone
from MS that "that is the stupidest f***king thing I ever
heard!", they will not take it personally, they will just
think that is your opinion on the subject and will probably
appreciate the fact you expressed it so directly..."
Read again and notice the sentences
- "not a malicious or mean-spirited thing";
- "nobody has time to worry about phrasing things in a way to avoid
hurting people's feelings";
- "people here are mostly thick-skinned enough to take all sorts of
criticism without being offended";
- and finally "they will not take it personally, they will just
think that is your opinion on the subject and will probably
appreciate the fact you expressed it so directly...".
Considering the time I waste with bruised egos (including mine) I got
a bit ashamed after reading this. I couldn't avoid thinking:
- "Now, from the time you can spend with mailing lists, look at the
percent you (me) just waste with ego-and-turf-defending sh*t instead
of doing something really constructive with it. And, if part of it is
settling down other's egos and personal sensitivities, a lot is
because of your (mine) own ego-and-lame-sensitivities crap!"
This is how I feel about it: a bit ashamed.
I also have an ego (big one) and also overreact and also get concerned
about defending positions I believe just as I am doing now... and
sometimes (maybe even now) I spend too much time defending those
positions.
What is too much time defending a position? Is when nothing really
positive can result for man kind except the fact that they will
understand that you (the defender) are right and are a great guy!
I do not expect to get perfect on this, but I sure can expect to get a
bit better. A bit less "too much".
The one thing I like most about Stefano is not the work I know from
him - Cocoon. There is a lot of principles I believe to be wrong there
(not in architecture/technical stuff, but in working model).
The one thing I like most about Stefano is:
- his enthusiasm, the way he tries to participate on all he can even if
only giving his possible 10 cents (in this case his opinion);
- (and especially) the fact that he as an ego but deals with it, giving
priority to have the BEST solution working instead of his solution.
(Never worked with him, but at least he publicly defends this. Not
everybody dares to do so.)
I think that it is a pity if we let "over defensiveness" get in the way
of creativity, enthusiasm and participation... even if 10 cent
participation.
And I do not even think that his style is very Italian.
Italian style is similar to very Portuguese very French or very
British. It is a "I am THE MAN and I am always right" style.
(By the way, I am Portuguese.)
Final "joke":
Being defensive again (me), I will note that I think that Ted,
although being over defensive, did not let that getting in the way of
appreciating Stefano opinion.
(Do you care about my opinion on this?????)
See???... I just spent almost an hour writing about this kind of
defensiveness crap with so much work to do!!!
=8o?
Argh!
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Arved Sandstrom [mailto:Arved_37@chebucto.ns.ca]
> Sent: Sunday, July 16, 2000 01:22
> To: xerces-j-dev@xml.apache.org
> Subject: Re: XRI requirements
>
>
> Hi, Ted
>
> As I understand it, Stefano's vote doesn't count. He's prolific,
> and takes
> an interest in a bunch of stuff, but I agree with you: the rule
> is that you
> have "walked the walk and not just talked the talk" before you
> get proposed
> as a committer, _within_ the particular Apache project.
>
> There is no way that you would want me, for example, as a committer right
> now, before I deliver some good material.
>
> I'd argue that we have been very good about doing this with FOP.
> There isn't
> a single person who is actually a committer who hasn't produced
> some sound
> contributions before being voted in. We have very solid people as
> committers.
>
> As I understand it, outside people can't vote. I have personally accorded
> weight to Stefano, but in my opinion he would not actually hold a
> vote. This
> has happened in FOP, also. I think we have always waited until there has
> been a preponderance of FOP committers voting.
>
> This sounds like "bust on Stefano" day, and maybe the guy does
> have a talent
> of being too honest. :-) I admit to being irritated a few times
> when he got
> overly enthusiastic in fop-dev. This is possibly a clash between
> my Estonian
> style and his Italian one. :-) That being said, he has definitely
> established himself as someone who "walks the walk" as well as
> "talking the
> talk". So I pay attention to him. :-)
>
> Arved
>
---------------------------------------------------------------------
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 - and overdefensiveness in OpenSourceLand...
Posted by Paulo Gaspar <pa...@krankikom.de>.
Well,
Stefano said:
> I'm not in the Xerces Dev team, but I would like to propose commit
> access for Ed.
And Ted answered
> As a procedural matter, can you propose commit access for Xerces? If so,
> can I propose commit access for Cocoon?
And it started looking like too much of turf defending.
But Ted also added:
> So, +1 on commit access on Ed, and a +1 from Duncan. Stefano also votes
> +1, but I don't know if his vote counts (other than I respect his opinion
> on matters like this).
And Ted started the first sentence with "As a procedural matter"!
I interpret this as "Ted respects Stefano opinion but is concerned with
procedural issues". It sounds like bureaucracy at work at Apache projects
huh?
But also notice that Stefano started is sentence as "I'm not in the Xerces
Dev team, but..." which sounds to me as "I know I have no vote but I still
would like to informally propose...".
But if it is informal, then Ted was over defensive and then Arved got
concerned with that and then so did I.
I do get concerned with this because I see everybody (including me) wasting
time by being over defensive in this and other mailing lists.
Now, maybe there is something here where we could learn from Microsoft best
practices (yes the big Satan!). This is a piece of an e-mail I got from a
Microsoft guy with whom I had a clash in another mailing list:
( Context: our clash got constructive very fast, he implemented something
I and others suggested, I checked on the first version and sent him a
mail suggesting improvements. Since I have a rough style of writing, I
added a note highlighting that even with a rough style it was meant as
constructive criticism.
What follows is part of his reply.
)
"As for the form that suggestions take, you should not worry
about offending me. One thing about Microsoft is that
we tend to take a very confrontational approach with
one another; not a malicious or mean-spirited thing,
it is just that people within MS are quick to tell
each other when they think something is stupid, and
also quick to admit they are wrong when proven wrong.
It seems that nobody has time to worry about phrasing
things in a way to avoid hurting people's feelings,
and people here are mostly thick-skinned enough to
take all sorts of criticism without being offended.
I really think that style of communication works great,
but we always have to remember not to do that with
customers :-) So anyway, usually if you tell someone
from MS that "that is the stupidest f***king thing I ever
heard!", they will not take it personally, they will just
think that is your opinion on the subject and will probably
appreciate the fact you expressed it so directly..."
Read again and notice the sentences
- "not a malicious or mean-spirited thing";
- "nobody has time to worry about phrasing things in a way to avoid
hurting people's feelings";
- "people here are mostly thick-skinned enough to take all sorts of
criticism without being offended";
- and finally "they will not take it personally, they will just
think that is your opinion on the subject and will probably
appreciate the fact you expressed it so directly...".
Considering the time I waste with bruised egos (including mine) I got
a bit ashamed after reading this. I couldn't avoid thinking:
- "Now, from the time you can spend with mailing lists, look at the
percent you (me) just waste with ego-and-turf-defending sh*t instead
of doing something really constructive with it. And, if part of it is
settling down other's egos and personal sensitivities, a lot is
because of your (mine) own ego-and-lame-sensitivities crap!"
This is how I feel about it: a bit ashamed.
I also have an ego (big one) and also overreact and also get concerned
about defending positions I believe just as I am doing now... and
sometimes (maybe even now) I spend too much time defending those
positions.
What is too much time defending a position? Is when nothing really
positive can result for man kind except the fact that they will
understand that you (the defender) are right and are a great guy!
I do not expect to get perfect on this, but I sure can expect to get a
bit better. A bit less "too much".
The one thing I like most about Stefano is not the work I know from
him - Cocoon. There is a lot of principles I believe to be wrong there
(not in architecture/technical stuff, but in working model).
The one thing I like most about Stefano is:
- his enthusiasm, the way he tries to participate on all he can even if
only giving his possible 10 cents (in this case his opinion);
- (and especially) the fact that he as an ego but deals with it, giving
priority to have the BEST solution working instead of his solution.
(Never worked with him, but at least he publicly defends this. Not
everybody dares to do so.)
I think that it is a pity if we let "over defensiveness" get in the way
of creativity, enthusiasm and participation... even if 10 cent
participation.
And I do not even think that his style is very Italian.
Italian style is similar to very Portuguese very French or very
British. It is a "I am THE MAN and I am always right" style.
(By the way, I am Portuguese.)
Final "joke":
Being defensive again (me), I will note that I think that Ted,
although being over defensive, did not let that getting in the way of
appreciating Stefano opinion.
(Do you care about my opinion on this?????)
See???... I just spent almost an hour writing about this kind of
defensiveness crap with so much work to do!!!
=8o?
Argh!
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Arved Sandstrom [mailto:Arved_37@chebucto.ns.ca]
> Sent: Sunday, July 16, 2000 01:22
> To: xerces-j-dev@xml.apache.org
> Subject: Re: XRI requirements
>
>
> Hi, Ted
>
> As I understand it, Stefano's vote doesn't count. He's prolific,
> and takes
> an interest in a bunch of stuff, but I agree with you: the rule
> is that you
> have "walked the walk and not just talked the talk" before you
> get proposed
> as a committer, _within_ the particular Apache project.
>
> There is no way that you would want me, for example, as a committer right
> now, before I deliver some good material.
>
> I'd argue that we have been very good about doing this with FOP.
> There isn't
> a single person who is actually a committer who hasn't produced
> some sound
> contributions before being voted in. We have very solid people as
> committers.
>
> As I understand it, outside people can't vote. I have personally accorded
> weight to Stefano, but in my opinion he would not actually hold a
> vote. This
> has happened in FOP, also. I think we have always waited until there has
> been a preponderance of FOP committers voting.
>
> This sounds like "bust on Stefano" day, and maybe the guy does
> have a talent
> of being too honest. :-) I admit to being irritated a few times
> when he got
> overly enthusiastic in fop-dev. This is possibly a clash between
> my Estonian
> style and his Italian one. :-) That being said, he has definitely
> established himself as someone who "walks the walk" as well as
> "talking the
> talk". So I pay attention to him. :-)
>
> Arved
>
Re: XRI requirements
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
Hi, Ted
As I understand it, Stefano's vote doesn't count. He's prolific, and takes
an interest in a bunch of stuff, but I agree with you: the rule is that you
have "walked the walk and not just talked the talk" before you get proposed
as a committer, _within_ the particular Apache project.
There is no way that you would want me, for example, as a committer right
now, before I deliver some good material.
I'd argue that we have been very good about doing this with FOP. There isn't
a single person who is actually a committer who hasn't produced some sound
contributions before being voted in. We have very solid people as committers.
As I understand it, outside people can't vote. I have personally accorded
weight to Stefano, but in my opinion he would not actually hold a vote. This
has happened in FOP, also. I think we have always waited until there has
been a preponderance of FOP committers voting.
This sounds like "bust on Stefano" day, and maybe the guy does have a talent
of being too honest. :-) I admit to being irritated a few times when he got
overly enthusiastic in fop-dev. This is possibly a clash between my Estonian
style and his Italian one. :-) That being said, he has definitely
established himself as someone who "walks the walk" as well as "talking the
talk". So I pay attention to him. :-)
Arved
At 03:02 PM 7/15/00 -0700, Ted Leung wrote:
>I'm copying this into xerces-j-dev so that we can get general cleaned
>up and so I can go back to reading only one incredibly busy mailing list.
>
>Let's continue this thread, and all the other XRI threads on xerces-j-dev.
>----- Original Message -----
>From: "Stefano Mazzocchi" <st...@apache.org>
>To: <ge...@xml.apache.org>
>Sent: Friday, July 14, 2000 12:07 PM
>Subject: Re: XRI requirements
>
>
>> > Ed Staub wrote:
>> >
>> > Thanks, Eric & Duncan.
>> >
>> > Ted Leung volunteered to work on this with me, and he's a committer.
>> > But he's going on vacation, so giving me rights probably makes sense,
>> > at least for the time being.
>> >
>> > I'm collating together a (hopefully) better list, with quotes and
>> > hrefs back to the mail archive.
>> >
>> > Here's an excerpt, for review of structure. We should have something
>> > real checked in tomorrow.
>>
>> I'm not in the Xerces Dev team, but I would like to propose commit
>> access for Ed.
>
>As a procedural matter, can you propose commit access for Xerces? If so,
>can I propose commit access for Cocoon?
>
>> Anyone against this?
>
>I'm not against it, but I do have a concern. The way that I understand it,
>we're supposed to grant commit access after someone has made a series
>of contributions. Granting commit access is the way that we ensure the
>quality of our meritocracy. We've been very lax about doing this (at least
>for Xerces) and this laxness has been part of the reason that people are
>walking on pins and needles around here. I think that we need to start
>doing a better job of this.
>
>James has already proposed commit access for Ed, and if he didn't I would.
>Here's my rationale. Ed has already posted a version of his requirements
>list for XRI. In my mind that's a significant contribution. It's not the
>nth in
>a series of contributions, but each re-posting and editing will be. So I'm
>fine
>with that. Given the low number of non-Sun and non-IBM commiters, I want
>to increase the number of such committers, but within the bounds of Apache
>practice. Perhaps we need to expand the notion of what someone must
>contribute
>in order to be a committer.
>
>I hate to sound like a lawyer on this -- maybe it's because I've had to deal
>with too many lately. We have very few rules in Apache, but the granting of
>comittter access and it's effect on the quality of the meritocracy is a very
>important one, perhaps the most important one. I want to make sure that
>everyone believes that we are doing our part to live up to "the Apache way".
>
>So, +1 on commit access on Ed, and a +1 from Duncan. Stefano also votes
>+1, but I don't know if his vote counts (other than I respect his opinion on
>matters like this). Of course, if Ed doesnt' get commit access, then I'll
>just commit
>stuff for him...
>
>Ted
>
>>
>> --
>> Stefano Mazzocchi One must still have chaos in oneself to be
>> able to give birth to a dancing star.
>> <st...@apache.org> Friedrich Nietzsche
>> --------------------------------------------------------------------
>> Missed us in Orlando? Make it up with ApacheCON Europe in London!
>> ------------------------- http://ApacheCon.Com ---------------------
>>
>>
>> ---------------------------------------------------------------------
>> In case of troubles, e-mail: webmaster@xml.apache.org
>> To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
>> For additional commands, e-mail: general-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
>
>
Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"
Re: XRI requirements
Posted by Ted Leung <tw...@sauria.com>.
I'm copying this into xerces-j-dev so that we can get general cleaned
up and so I can go back to reading only one incredibly busy mailing list.
Let's continue this thread, and all the other XRI threads on xerces-j-dev.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <ge...@xml.apache.org>
Sent: Friday, July 14, 2000 12:07 PM
Subject: Re: XRI requirements
> > Ed Staub wrote:
> >
> > Thanks, Eric & Duncan.
> >
> > Ted Leung volunteered to work on this with me, and he's a committer.
> > But he's going on vacation, so giving me rights probably makes sense,
> > at least for the time being.
> >
> > I'm collating together a (hopefully) better list, with quotes and
> > hrefs back to the mail archive.
> >
> > Here's an excerpt, for review of structure. We should have something
> > real checked in tomorrow.
>
> I'm not in the Xerces Dev team, but I would like to propose commit
> access for Ed.
As a procedural matter, can you propose commit access for Xerces? If so,
can I propose commit access for Cocoon?
> Anyone against this?
I'm not against it, but I do have a concern. The way that I understand it,
we're supposed to grant commit access after someone has made a series
of contributions. Granting commit access is the way that we ensure the
quality of our meritocracy. We've been very lax about doing this (at least
for Xerces) and this laxness has been part of the reason that people are
walking on pins and needles around here. I think that we need to start
doing a better job of this.
James has already proposed commit access for Ed, and if he didn't I would.
Here's my rationale. Ed has already posted a version of his requirements
list for XRI. In my mind that's a significant contribution. It's not the
nth in
a series of contributions, but each re-posting and editing will be. So I'm
fine
with that. Given the low number of non-Sun and non-IBM commiters, I want
to increase the number of such committers, but within the bounds of Apache
practice. Perhaps we need to expand the notion of what someone must
contribute
in order to be a committer.
I hate to sound like a lawyer on this -- maybe it's because I've had to deal
with too many lately. We have very few rules in Apache, but the granting of
comittter access and it's effect on the quality of the meritocracy is a very
important one, perhaps the most important one. I want to make sure that
everyone believes that we are doing our part to live up to "the Apache way".
So, +1 on commit access on Ed, and a +1 from Duncan. Stefano also votes
+1, but I don't know if his vote counts (other than I respect his opinion on
matters like this). Of course, if Ed doesnt' get commit access, then I'll
just commit
stuff for him...
Ted
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
> Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------
>
>
> ---------------------------------------------------------------------
> In case of troubles, e-mail: webmaster@xml.apache.org
> To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
>
>
>
Re: XRI requirements
Posted by Ted Leung <tw...@sauria.com>.
I'm copying this into xerces-j-dev so that we can get general cleaned
up and so I can go back to reading only one incredibly busy mailing list.
Let's continue this thread, and all the other XRI threads on xerces-j-dev.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <ge...@xml.apache.org>
Sent: Friday, July 14, 2000 12:07 PM
Subject: Re: XRI requirements
> > Ed Staub wrote:
> >
> > Thanks, Eric & Duncan.
> >
> > Ted Leung volunteered to work on this with me, and he's a committer.
> > But he's going on vacation, so giving me rights probably makes sense,
> > at least for the time being.
> >
> > I'm collating together a (hopefully) better list, with quotes and
> > hrefs back to the mail archive.
> >
> > Here's an excerpt, for review of structure. We should have something
> > real checked in tomorrow.
>
> I'm not in the Xerces Dev team, but I would like to propose commit
> access for Ed.
As a procedural matter, can you propose commit access for Xerces? If so,
can I propose commit access for Cocoon?
> Anyone against this?
I'm not against it, but I do have a concern. The way that I understand it,
we're supposed to grant commit access after someone has made a series
of contributions. Granting commit access is the way that we ensure the
quality of our meritocracy. We've been very lax about doing this (at least
for Xerces) and this laxness has been part of the reason that people are
walking on pins and needles around here. I think that we need to start
doing a better job of this.
James has already proposed commit access for Ed, and if he didn't I would.
Here's my rationale. Ed has already posted a version of his requirements
list for XRI. In my mind that's a significant contribution. It's not the
nth in
a series of contributions, but each re-posting and editing will be. So I'm
fine
with that. Given the low number of non-Sun and non-IBM commiters, I want
to increase the number of such committers, but within the bounds of Apache
practice. Perhaps we need to expand the notion of what someone must
contribute
in order to be a committer.
I hate to sound like a lawyer on this -- maybe it's because I've had to deal
with too many lately. We have very few rules in Apache, but the granting of
comittter access and it's effect on the quality of the meritocracy is a very
important one, perhaps the most important one. I want to make sure that
everyone believes that we are doing our part to live up to "the Apache way".
So, +1 on commit access on Ed, and a +1 from Duncan. Stefano also votes
+1, but I don't know if his vote counts (other than I respect his opinion on
matters like this). Of course, if Ed doesnt' get commit access, then I'll
just commit
stuff for him...
Ted
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
> Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------
>
>
> ---------------------------------------------------------------------
> In case of troubles, e-mail: webmaster@xml.apache.org
> To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
>
>
>
Re: XRI requirements
Posted by Stefano Mazzocchi <st...@apache.org>.
> Ed Staub wrote:
>
> Thanks, Eric & Duncan.
>
> Ted Leung volunteered to work on this with me, and he's a committer.
> But he's going on vacation, so giving me rights probably makes sense,
> at least for the time being.
>
> I'm collating together a (hopefully) better list, with quotes and
> hrefs back to the mail archive.
>
> Here's an excerpt, for review of structure. We should have something
> real checked in tomorrow.
I'm not in the Xerces Dev team, but I would like to propose commit
access for Ed.
Anyone against this?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: XRI requirements
Posted by James Duncan Davidson <ja...@eng.sun.com>.
> on 7/14/00 5:03 AM, Ed Staub at estaub@mediaone.net wrote:
>
> Here's an excerpt, for review of structure. We should have something real
> checked in tomorrow.
I like the format of the saple -- especially the form of the hrefs. Very
nice.
About that parser output before input idea... :) (I now have visions of the
STNG episode where time became a loop...)
.duncan
RE: XRI requirements
Posted by Ed Staub <es...@mediaone.net>.
Thanks, Eric & Duncan.
Ted Leung volunteered to work on this with me, and he's a committer.
But he's going on vacation, so giving me rights probably makes sense, at
least for the time being.
I'm collating together a (hopefully) better list, with quotes and hrefs back
to the mail archive.
Here's an excerpt, for review of structure. We should have something real
checked in tomorrow.
----------------------------------------------------------------------------
----
Schema
Proposed requirements are organized into categories. Some requirements may
occur in more than one category in the future.
Each requirement has a number. The numbers are not in any useful order, but
will remain stable for reference. Underneath the number is a "hardness" and
"status".
Possible "hardness" values are:
hard - Xerces 2 must and shall meet this requirement
soft - Xerces 2 should meet this requirement, but it may be dropped
because of conflicting requirements or time pressures
Possible "status" values are:
approved - there appears to be a clear consensus
tooQuiet - there may be a consensus, but there hasn't been enough input to
be sure
hardnessConflict - there is conflict over whether this is a hard or soft
requirement
vetoConflict - there is a conflict over whether this proposed requirement
is a requirement at all
rejected - the proposed requirement appears to be dead
unevaluated - editor hasn't finished reviewing input
----------------------------------------------------------------------------
----
An example entry:
1.
hard
rejected
The parser shall be faster than the speed of light.
"Parser output must occur before parser input..." [spinnaker]
Announce James Duncan Davidson (Sat Jul 08 2000 - 07:31:16 MEST)
a..
"Transluminal parsing speeds could cause a rip in the space-time
continuum..." Re: [spinnaker] Announce Stefano Mazzocchi (Sun Jul 09 2000 -
17:36:18 MEST)
-Ed
-----Original Message-----
From: James Duncan Davidson [mailto:james.davidson@eng.sun.com]
Sent: Friday, July 14, 2000 12:39 AM
To: general@xml.apache.org
Subject: Re: XRI requirements
on 7/12/00 10:25 AM, Eric Ye at ericye@locus.apache.org wrote:
> Thanks, Ed, for compiling all this requirements. why can't you be the
> person to continue doing this job? I don't see any problems.
In fact if the problem is that he doesn't have commit access, let's take
care of that -- if he's willing to keep the requirements and further design
docs together (granted, everyone should work on them, but.. It's nice to
have a point person as long as they are willing) -- then I'd propose he be a
committer.
.duncan
---------------------------------------------------------------------
In case of troubles, e-mail: webmaster@xml.apache.org
To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org
Re: XRI requirements
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 7/12/00 10:25 AM, Eric Ye at ericye@locus.apache.org wrote:
> Thanks, Ed, for compiling all this requirements. why can't you be the
> person to continue doing this job? I don't see any problems.
In fact if the problem is that he doesn't have commit access, let's take
care of that -- if he's willing to keep the requirements and further design
docs together (granted, everyone should work on them, but.. It's nice to
have a point person as long as they are willing) -- then I'd propose he be a
committer.
.duncan
Re: XRI requirements
Posted by Eric Ye <er...@locus.apache.org>.
Thanks, Ed, for compiling all this requirements. why can't you be the
person to continue doing this job? I don't see any problems.
_____
Eric Ye * IBM, JTC - Silicon Valley * ericye@locus.apache.org
----- Original Message -----
From: "Ed Staub" <es...@mediaone.net>
To: <ge...@xml.apache.org>
Sent: Tuesday, July 11, 2000 9:03 PM
Subject: XRI requirements
> Here's a quick copy-and-paste list of the proposed
> XRI/Spinnaker/Xerces-2/X2/XRay requirements which have been discussed by
> various people over the last few days. (Ok, I just threw in "X2" and
> "XRay"!;) I did some light editing for clarity. I probably missed a few!
>
> If folks would like me to do more with the proposed requirements list,
> please let me know and I'll propose some procedures and (better!)
> formatting. But I suspect that it may be desirable to have a more
> well-known and experienced person recording the proposed requirements.
It's
> clearly a sensitive area where a person widely believed to be impartial
> would be very valuable.
>
> Regardless... what's missing?
>
> -Ed Staub
>
>
> FEATURES and STANDARDS COMPLIANCE
> ---------------------------------
>
> Validating XML 1.0 support
>
> Namespace support
>
> SAX2 support
>
> DOM Level 2 support
>
> XML Schema support
>
> XPath support
>
> XInclude support
>
> Write validation of a DOM tree or revalidation
>
> Grammar access for both DTD and Schema.
>
> Document-order indexes or API as a DOM extension.
>
> [optional] isWhite() method as a DOM extensions (pure telling of
> whether or not the text contains non-whitespace), for performance reasons.
>
> Serialization support, as is currently in Assaf's classes.
>
> PERFORMANCE
> -----------
>
> No significant speed penalty for unused features, notably validation.
>
> Best-of-breed performance across all JIT's (not just Hotspot).
>
> Grammar caching, pre-compiled grammar can be cached to validate instance
> documents over and over again without re-reading the DTD and Schema file
or
> even compile it.
>
> A configurable parser, in line with the requirements of Modularity and
> pluggable Validator somebody posted before. Not only should the validator
> be pluggable, but also if there is a need for a parser without validation
at
> all, there should be some parser configuration which is really lightweight
> and just scans, checks well-formedness, and generates SAX2 events. Or
even
> fancier, a brand new functional module can be plugged in BETWEEN
components
> as long as it implements certain interfaces. [Eric Ye]
>
> Mid to upper range validation performance across all JVMs.
>
> Read-only, memory conservative, high performance DOM subset (for Xalan et
> al)
>
> Parsing in chunks [Scott Boag]
>
> A reasonable core (fast!) upon which to layer JDOM [Brett M.]
>
> Some sort of weak reference, where nodes could be released if not
> referenced, and then rebuilt if requested. For performance and memory
> footprint.
>
> Some sort of way to tell if a SAX char buffer is going to be
> overwritten, so data doesn't have to be copied until this occurs.
>
> Small core footprint for standalone, compiled stylesheet capability, for
> use on small devices. This would need to include the Serializer. I'm not
> sure if this should really be a separate micro-parser?
>
> Smallest possible size. This means small distribution size (JAR
> file) and small memory footprint.
>
>
> OTHER QUALITIES
> ----------------
>
> Clarity of design and code sufficient to encourage wide participation.
> Code should always be readable and maintainable.
>
> Design portable to C++ (or elsewhere)
>
> More documentation on the Apache web site not only for users but for
> DEVELOPERs.
>
> Testcases for both conformance and benchmarking.
>
>
> ===============================
>
> NOMINAL NON-REQUIREMENTS:
>
> Someone stated, without dissent (yet!), that these do not need to be
> supported:
>
> SAX 1 support
>
>
> ---------------------------------------------------------------------
> In case of troubles, e-mail: webmaster@xml.apache.org
> To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
>
>
Re: XRI requirements
Posted by Ted Leung <tw...@sauria.com>.
I'm a little behind on the mail, but I'd be happy to do this along with Ed.
I do think it is important for one of the Xerces comitters to work on this,
because I think that the requirements list should go in the repository.
----- Original Message -----
From: "Ed Staub" <es...@mediaone.net>
To: <ge...@xml.apache.org>
Sent: Tuesday, July 11, 2000 9:03 PM
Subject: XRI requirements
> Here's a quick copy-and-paste list of the proposed
> XRI/Spinnaker/Xerces-2/X2/XRay requirements which have been discussed by
> various people over the last few days. (Ok, I just threw in "X2" and
> "XRay"!;) I did some light editing for clarity. I probably missed a few!
>
> If folks would like me to do more with the proposed requirements list,
> please let me know and I'll propose some procedures and (better!)
> formatting. But I suspect that it may be desirable to have a more
> well-known and experienced person recording the proposed requirements.
It's
> clearly a sensitive area where a person widely believed to be impartial
> would be very valuable.
>
> Regardless... what's missing?
>
> -Ed Staub
>
>
> FEATURES and STANDARDS COMPLIANCE
> ---------------------------------
>
> Validating XML 1.0 support
>
> Namespace support
>
> SAX2 support
>
> DOM Level 2 support
>
> XML Schema support
>
> XPath support
>
> XInclude support
>
> Write validation of a DOM tree or revalidation
>
> Grammar access for both DTD and Schema.
>
> Document-order indexes or API as a DOM extension.
>
> [optional] isWhite() method as a DOM extensions (pure telling of
> whether or not the text contains non-whitespace), for performance reasons.
>
> Serialization support, as is currently in Assaf's classes.
>
> PERFORMANCE
> -----------
>
> No significant speed penalty for unused features, notably validation.
>
> Best-of-breed performance across all JIT's (not just Hotspot).
>
> Grammar caching, pre-compiled grammar can be cached to validate instance
> documents over and over again without re-reading the DTD and Schema file
or
> even compile it.
>
> A configurable parser, in line with the requirements of Modularity and
> pluggable Validator somebody posted before. Not only should the validator
> be pluggable, but also if there is a need for a parser without validation
at
> all, there should be some parser configuration which is really lightweight
> and just scans, checks well-formedness, and generates SAX2 events. Or
even
> fancier, a brand new functional module can be plugged in BETWEEN
components
> as long as it implements certain interfaces. [Eric Ye]
>
> Mid to upper range validation performance across all JVMs.
>
> Read-only, memory conservative, high performance DOM subset (for Xalan et
> al)
>
> Parsing in chunks [Scott Boag]
>
> A reasonable core (fast!) upon which to layer JDOM [Brett M.]
>
> Some sort of weak reference, where nodes could be released if not
> referenced, and then rebuilt if requested. For performance and memory
> footprint.
>
> Some sort of way to tell if a SAX char buffer is going to be
> overwritten, so data doesn't have to be copied until this occurs.
>
> Small core footprint for standalone, compiled stylesheet capability, for
> use on small devices. This would need to include the Serializer. I'm not
> sure if this should really be a separate micro-parser?
>
> Smallest possible size. This means small distribution size (JAR
> file) and small memory footprint.
>
>
> OTHER QUALITIES
> ----------------
>
> Clarity of design and code sufficient to encourage wide participation.
> Code should always be readable and maintainable.
>
> Design portable to C++ (or elsewhere)
>
> More documentation on the Apache web site not only for users but for
> DEVELOPERs.
>
> Testcases for both conformance and benchmarking.
>
>
> ===============================
>
> NOMINAL NON-REQUIREMENTS:
>
> Someone stated, without dissent (yet!), that these do not need to be
> supported:
>
> SAX 1 support
>
>
> ---------------------------------------------------------------------
> In case of troubles, e-mail: webmaster@xml.apache.org
> To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
>
>
>