XRI design ideas

[Mikael Helbo Kjær <mh...@dia.dk>]

I have taken up the idea to compile a text document containing the suggested
design and philosophies of the new XRI project parser. I have a handle on
most of the project, but since the commiter are those doing actual work on
this I would like it, if they as well as anybody else posted the design of
anything that they have already done as well as anything they have ideas
for. I think we can agree that we have talked and I have the additional
thoughts on the following:

-the Xerces package must contain support for DOM(the level of the DOM yet to
be agreed) and SAX2.

-the actual classes for building the DOM or to spit out SAX event should be
decoupled from the Parser core to allow for support for new XML data storage
models

-the internal way to handle xml is still up in the air. There are two ways
which I have seen being discussed: A Push model parser and a Pull model
parser, but both models still lack some what in clarity before being ready
for development.

-to facilitate the modularity of the Parser design, mechanism for plugging
in Entity resolving, Grammar handling, XInclude and the like was discussed.
This should also provide for a way to future proof the XRI result, if this
mechanism is made general enough to make sure that anything new from the W3C
needing to be plugged into the Parser can be.

-there still needs to be some discussion about the DOM implementation of the
XRI. Are there anything new we can try to improve the footprint and
construction performance of the DOM

-there still needs to be some discussion about the SAX implementation of the
XRI. Are there any new developments on SAX that we need to be prepared for. 

-should there be some kind of general controller class containing references
to all instansiated functions within the Parser to allow for some kind of
current configuration metadata to be extracted as well as functioning as a
reference library for the different plugged in modules to communicate with
the Parser and each other (just a wacked out idea I have).

So I would like everyone to add to this. This is NOT the requirements
documents, this is meant to clarify and ready our minds to implement the
Requirements document. The combination of the Requirements document and the
design documents created here should contain the roadmap of development for
the Parser we want to create. It should also provide a great way for new
committers to "grab" a feature and begin creating it. This will probably
make progress on XRI much faster. 

Oh, BTW the reason I didn`t use Xerces 2 in my document is that I haven`t
seen the results of the vote of committers (valid votes) tallied and posted
on the list.
If the voting process is to work we need to be alot more serious about our
votes. A vote declaration should be requested then the list/project
coordinator post a mail with the issue request as well as a list of the
people allowed to vote on the subject. This way I can disregard votes by
non-committers and actually see a result of each vote. Finally we need a
little more discipline on the list regarding decisions on matters, this also
means declaring when a vote is over and posting a mail explaining the
result. This is serious business people. Open source isn`t just sending an
occasional mail to list of people and maintaining a public CVS mirror of
former internal code. I know the IBM people is doing a great job on the
Xerces-J, but they`re doing a lousy job at community building and managing.
We should this right, we`ll all be happier with the result believe me. I am
saying that maybe we should make some one outside of IBM and Sun the
list/project coordinator, then we would see all decisions and discussions
passing between the developers. I am not saying your doing a bad job at
working on Xerces, but you`re by far not open enough and I believe you could
and want to be. If you disagree just say so, but also say why. Have I
misunderstood the purpose and way the Apache projects run, then say so I
will modify my views (if they`re wrong). Finally thank you IBM for making
this discussion even possible by giving the Apache project something as cool
as their server to a part of the community namely Xerces (in all it`s
editions be it Java, C++ or COM).

Mikael Helbo Kjær
Software Developer @ DIA a/s

Please help: SAX Serialization Problem.

[Vincent-Olivier Arsenault <vi...@neuro6.com>]

i can find tons of matches on the archive but since it's down, I can't read
anything....

i'm trying to get a thread-safe way of SAX serializing.

...

HTMLSerializer htmlSerializer = (HTMLSerializer)
htmlfactory.makeSerializer( out, htmlformat).asDocumentHandler();

This doesn't work as it returns the same DocumentHandler everytimes
asDocumentHandler() is called (seems so, because if this is called by many
threads, the last one gets all the other's output!).

please, please help me.



thanks

vincent.

Re: XRI design ideas

[Mike Pogue <mp...@apache.org>]

Scott Ellsworth wrote:
...
> A list of current bugs is one thing, but a mechanism to add to that list is
> even more important.  Being able to search the open problems just to see if
> my problem is known would help as well.  Finding bugs is a worthy part of
> the effort, even if one does not contribute code.
>

I completely agree, and we have been asking for this from the Powers that Be for many
months now.  We had Bugzilla, which worked nicely (anybody could submit a bug report, they
were searchable, etc.), but it had security problems, so it's been disabled.

Whether we get any kind of bug tracking back again is completely NOT up to the committers
on this mailing list.  (Believe me, all the committers want it!)

Anybody want to setup a Source Forge project to do this?

Mike

Re: XRI design ideas

[Eric Ye <er...@locus.apache.org>]

> One of those contributing factors is the difficulty of getting a bug
> acknowledged, confirmed, and on someone's fix list.  A sexy bug posted to
> the mailing list gets discussion, but something a bit more plebian is not
> going to get a lot of notice.
>
> For example, I posted one where xerces failed to find my dtd files if it
> was in a directory with a space in the path, but succeeded if there were
no
> space in the path.  The FAQ tells me that I could likely escape things and
> make it work if the path were one I specified, but these were plain old
> relative paths where xerces added the default.  Once it added the default,
> it could not deal with the default it added.  I can't yet find and fix it,
> but I can see it happen.  Unless this bug happens to catch the eye of a
> developer, it will never make the list of things to fix.
>
> A list of current bugs is one thing, but a mechanism to add to that list
is
> even more important.  Being able to search the open problems just to see
if
> my problem is known would help as well.  Finding bugs is a worthy part of
> the effort, even if one does not contribute code.
>
> Scott
> Scott Ellsworth
> scott@alodar.com
>

A bug tracking system accessible to the Xerces community is really in
desperate need. Suggestions and volunteering are welcome on setting up a
secure web-based bug tracking system for Xerces project.  We already learned
lessons from previously attacked Bugzila system installed on Locus, but I
was wondering how come Mozilla's bugzilla system is still running ?? anybody
konws.

_____


Eric Ye * IBM, JTC - Silicon Valley * ericye@locus.apache.org

Re: XRI design ideas

[Scott Ellsworth <sc...@alodar.com>]

At 10:44 AM 8/7/2000 -0700, Eric Ye wrote:
>Great point, and very well put. Then we should exploit those contributing
>factors that cause the lack of contributors and knock them off, since we 
>can see so many people really care about this open source project and 
>possess the capability to help make things happen.

One of those contributing factors is the difficulty of getting a bug 
acknowledged, confirmed, and on someone's fix list.  A sexy bug posted to 
the mailing list gets discussion, but something a bit more plebian is not 
going to get a lot of notice.

For example, I posted one where xerces failed to find my dtd files if it 
was in a directory with a space in the path, but succeeded if there were no 
space in the path.  The FAQ tells me that I could likely escape things and 
make it work if the path were one I specified, but these were plain old 
relative paths where xerces added the default.  Once it added the default, 
it could not deal with the default it added.  I can't yet find and fix it, 
but I can see it happen.  Unless this bug happens to catch the eye of a 
developer, it will never make the list of things to fix.

A list of current bugs is one thing, but a mechanism to add to that list is 
even more important.  Being able to search the open problems just to see if 
my problem is known would help as well.  Finding bugs is a worthy part of 
the effort, even if one does not contribute code.

Scott
Scott Ellsworth
scott@alodar.com

Re: XRI design ideas

[Eric Ye <er...@locus.apache.org>]

Great point, and very well put. Then we should exploit those contributing
factors that cause the lack of contributors and knock them off, since we can
see so many people really care about this open source project and possess
the capability to help make things happen.
_____


Eric Ye * IBM, JTC - Silicon Valley * ericye@locus.apache.org

----- Original Message -----
From: "Ed Staub" <es...@mediaone.net>
To: <xe...@xml.apache.org>
Sent: Monday, August 07, 2000 8:25 AM
Subject: RE: XRI design ideas


> Cool!
>
> >If the voting process is to work we need to be alot more serious about
our
> >votes. A vote declaration should be requested then the list/project
> >coordinator post a mail with the issue request as well as a list of the
> >people allowed to vote on the subject.
>
> Yes!  I know Ted is also concerned in this area, hence his call for a vote
> on the name a week ago.  I'd expect to see a tally imminently.
>
> As far as the IBM group goes... I think you're right that if the external
> community is going to expect that the group becomes more open, it must
> provide the means for that to happen, through code contribution, volunteer
> facilitators and other participation beyond mailing-list discourse.  If
> there isn't meaningful external participation _beyond_ ordinary concerned
> consumership, then the IBM group will naturally remain somewhat turned
> inward, as it has.  Regardless, people who can work together in a
> face-to-face environment ought to be able to exploit the opportunity for
> discourse without feeling guilty!
>
> If Apache is to remain the meritocracy that it has been, then the IBM
group
> should wield a lot of power, because they're doing most of the work.  If
> more people were contributing, this would be less of an issue.  Of course,
> there are a lot of contributing factors causing the lack of contributors.
> ;)
>
> -Ed Staub
>
>
> -----Original Message-----
> From: Mikael Helbo Kjær [mailto:mhk@dia.dk]
> Sent: Monday, August 07, 2000 3:34 AM
> To: 'xerces-j-dev@xml.apache.org'
> Subject: XRI design ideas
>
> I have taken up the idea to compile a text document containing the
suggested
> design and philosophies of the new XRI project parser. I have a handle on
> most of the project, but since the commiter are those doing actual work on
> this I would like it, if they as well as anybody else posted the design of
> anything that they have already done as well as anything they have ideas
> for. I think we can agree that we have talked and I have the additional
> thoughts on the following:
>
> -the Xerces package must contain support for DOM(the level of the DOM yet
to
> be agreed) and SAX2.
>
> -the actual classes for building the DOM or to spit out SAX event should
be
> decoupled from the Parser core to allow for support for new XML data
storage
> models
>
> -the internal way to handle xml is still up in the air. There are two ways
> which I have seen being discussed: A Push model parser and a Pull model
> parser, but both models still lack some what in clarity before being ready
> for development.
>
> -to facilitate the modularity of the Parser design, mechanism for plugging
> in Entity resolving, Grammar handling, XInclude and the like was
discussed.
> This should also provide for a way to future proof the XRI result, if this
> mechanism is made general enough to make sure that anything new from the
W3C
> needing to be plugged into the Parser can be.
>
> -there still needs to be some discussion about the DOM implementation of
the
> XRI. Are there anything new we can try to improve the footprint and
> construction performance of the DOM
>
> -there still needs to be some discussion about the SAX implementation of
the
> XRI. Are there any new developments on SAX that we need to be prepared
for.
>
> -should there be some kind of general controller class containing
references
> to all instansiated functions within the Parser to allow for some kind of
> current configuration metadata to be extracted as well as functioning as a
> reference library for the different plugged in modules to communicate with
> the Parser and each other (just a wacked out idea I have).
>
> So I would like everyone to add to this. This is NOT the requirements
> documents, this is meant to clarify and ready our minds to implement the
> Requirements document. The combination of the Requirements document and
the
> design documents created here should contain the roadmap of development
for
> the Parser we want to create. It should also provide a great way for new
> committers to "grab" a feature and begin creating it. This will probably
> make progress on XRI much faster.
>
> Oh, BTW the reason I didn`t use Xerces 2 in my document is that I haven`t
> seen the results of the vote of committers (valid votes) tallied and
posted
> on the list.
> If the voting process is to work we need to be alot more serious about our
> votes. A vote declaration should be requested then the list/project
> coordinator post a mail with the issue request as well as a list of the
> people allowed to vote on the subject. This way I can disregard votes by
> non-committers and actually see a result of each vote. Finally we need a
> little more discipline on the list regarding decisions on matters, this
also
> means declaring when a vote is over and posting a mail explaining the
> result. This is serious business people. Open source isn`t just sending an
> occasional mail to list of people and maintaining a public CVS mirror of
> former internal code. I know the IBM people is doing a great job on the
> Xerces-J, but they`re doing a lousy job at community building and
managing.
> We should this right, we`ll all be happier with the result believe me. I
am
> saying that maybe we should make some one outside of IBM and Sun the
> list/project coordinator, then we would see all decisions and discussions
> passing between the developers. I am not saying your doing a bad job at
> working on Xerces, but you`re by far not open enough and I believe you
could
> and want to be. If you disagree just say so, but also say why. Have I
> misunderstood the purpose and way the Apache projects run, then say so I
> will modify my views (if they`re wrong). Finally thank you IBM for making
> this discussion even possible by giving the Apache project something as
cool
> as their server to a part of the community namely Xerces (in all it`s
> editions be it Java, C++ or COM).
>
> Mikael Helbo Kjær
> Software Developer @ DIA a/s
>
> ---------------------------------------------------------------------
> 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: XRI design ideas

[Ed Staub <es...@mediaone.net>]

Cool!

>If the voting process is to work we need to be alot more serious about our
>votes. A vote declaration should be requested then the list/project
>coordinator post a mail with the issue request as well as a list of the
>people allowed to vote on the subject.

Yes!  I know Ted is also concerned in this area, hence his call for a vote
on the name a week ago.  I'd expect to see a tally imminently.

As far as the IBM group goes... I think you're right that if the external
community is going to expect that the group becomes more open, it must
provide the means for that to happen, through code contribution, volunteer
facilitators and other participation beyond mailing-list discourse.  If
there isn't meaningful external participation _beyond_ ordinary concerned
consumership, then the IBM group will naturally remain somewhat turned
inward, as it has.  Regardless, people who can work together in a
face-to-face environment ought to be able to exploit the opportunity for
discourse without feeling guilty!

If Apache is to remain the meritocracy that it has been, then the IBM group
should wield a lot of power, because they're doing most of the work.  If
more people were contributing, this would be less of an issue.  Of course,
there are a lot of contributing factors causing the lack of contributors.
;)

-Ed Staub


-----Original Message-----
From: Mikael Helbo Kjær [mailto:mhk@dia.dk]
Sent: Monday, August 07, 2000 3:34 AM
To: 'xerces-j-dev@xml.apache.org'
Subject: XRI design ideas

I have taken up the idea to compile a text document containing the suggested
design and philosophies of the new XRI project parser. I have a handle on
most of the project, but since the commiter are those doing actual work on
this I would like it, if they as well as anybody else posted the design of
anything that they have already done as well as anything they have ideas
for. I think we can agree that we have talked and I have the additional
thoughts on the following:

-the Xerces package must contain support for DOM(the level of the DOM yet to
be agreed) and SAX2.

-the actual classes for building the DOM or to spit out SAX event should be
decoupled from the Parser core to allow for support for new XML data storage
models

-the internal way to handle xml is still up in the air. There are two ways
which I have seen being discussed: A Push model parser and a Pull model
parser, but both models still lack some what in clarity before being ready
for development.

-to facilitate the modularity of the Parser design, mechanism for plugging
in Entity resolving, Grammar handling, XInclude and the like was discussed.
This should also provide for a way to future proof the XRI result, if this
mechanism is made general enough to make sure that anything new from the W3C
needing to be plugged into the Parser can be.

-there still needs to be some discussion about the DOM implementation of the
XRI. Are there anything new we can try to improve the footprint and
construction performance of the DOM

-there still needs to be some discussion about the SAX implementation of the
XRI. Are there any new developments on SAX that we need to be prepared for.

-should there be some kind of general controller class containing references
to all instansiated functions within the Parser to allow for some kind of
current configuration metadata to be extracted as well as functioning as a
reference library for the different plugged in modules to communicate with
the Parser and each other (just a wacked out idea I have).

So I would like everyone to add to this. This is NOT the requirements
documents, this is meant to clarify and ready our minds to implement the
Requirements document. The combination of the Requirements document and the
design documents created here should contain the roadmap of development for
the Parser we want to create. It should also provide a great way for new
committers to "grab" a feature and begin creating it. This will probably
make progress on XRI much faster.

Oh, BTW the reason I didn`t use Xerces 2 in my document is that I haven`t
seen the results of the vote of committers (valid votes) tallied and posted
on the list.
If the voting process is to work we need to be alot more serious about our
votes. A vote declaration should be requested then the list/project
coordinator post a mail with the issue request as well as a list of the
people allowed to vote on the subject. This way I can disregard votes by
non-committers and actually see a result of each vote. Finally we need a
little more discipline on the list regarding decisions on matters, this also
means declaring when a vote is over and posting a mail explaining the
result. This is serious business people. Open source isn`t just sending an
occasional mail to list of people and maintaining a public CVS mirror of
former internal code. I know the IBM people is doing a great job on the
Xerces-J, but they`re doing a lousy job at community building and managing.
We should this right, we`ll all be happier with the result believe me. I am
saying that maybe we should make some one outside of IBM and Sun the
list/project coordinator, then we would see all decisions and discussions
passing between the developers. I am not saying your doing a bad job at
working on Xerces, but you`re by far not open enough and I believe you could
and want to be. If you disagree just say so, but also say why. Have I
misunderstood the purpose and way the Apache projects run, then say so I
will modify my views (if they`re wrong). Finally thank you IBM for making
this discussion even possible by giving the Apache project something as cool
as their server to a part of the community namely Xerces (in all it`s
editions be it Java, C++ or COM).

Mikael Helbo Kjær
Software Developer @ DIA a/s

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org