cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <ar...@exoffice.com>
Subject Re: Deep testing before release
Date Mon, 13 Dec 1999 19:16:13 GMT
On the contrary, I would prefer the OpenXML be pulled out from this
release. I'm now busy getting OpenXML integrated with Xerces and would
rather focus on that than fixing OpenXML bugs.

Right now I am using Xerces for all XML functionality, OpenXML for HTML
functionality, and I've got the OpenXML HTML DOM to build on top of
Xerces. The HTML parser will be migrated soon, at which point I'm likley
to eliminate the OpenXML DOM altogether.

arkin


Stefano Mazzocchi wrote:
> 
> People,
> 
> I plan to make a the Cocoon 1.6 release as soon as Donald and Ricardo
> have completed the XML-ization of their respective documentation files.
> 
> Meanwhile, I've done some regression tests and found out that neither
> latest OpenXML nor XSLP are enough stable to provide a drop-in
> replacement for the other supported parsers/processors.
> 
> For OpenXML, some limitations and some parsing exceptions prevent
> complete operation with Xalan, with DCP and some FO page due to
> (probably) DOM bugs. I'm more than willing to submit bug reports to
> Assaf in order for him to fix these, but I would like to know the
> planned future of this project before doing so since I know Arkin has
> already merged OpenXML features into Xerces so continuing its support
> might not be worthwhile for us.
> 
> Also, rather than compliance and performance issues (in which neither
> OpenXML excels, it also doesn't perform validation), you should _not_
> have any need for have a specific XML parser.
> 
> I propose to leave the glue classes in the Cocoon distribution but to
> remove the configuration lines from the cocoon.properties file.
> 
> For XSLP, conformance is the first problem: while XT and Xalan have
> almost the same conformance level, XSLP is rather behind and I'm not
> sure it's support is worth the number of bugs reports that would be
> generated due to its lack of compliance to the final spec.
> 
> Also, the need for hardcoded configurations for parser use might create
> more troubles and bug reports than we want to handle.
> 
> So, also for XSLP, I proose to remove the lines in cocoon.properties but
> leave the classes/code for back compatibility issues.
> 
> Assaf, Keith: please, don't take this action in the wrong way. You know
> how much I am grateful to both of you for your wonderful work on this
> area, but I think, given the current status and given your focus shift
> at ExOffice, it's better for everyone to concentrate on working
> solutions and exit the "alpha" stage.
> 
> I'm not talking about code stability here (the bugs in OpenXML I'm sure
> are minor and I didn't find weak points in XSLP operation), but
> compliance, performance and usability.
> 
> So, all of you, make yourself heard: do you think of my proposals?
> 
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche

-- 
____________________________________________________________
Assaf Arkin                               arkin@exoffice.com
CTO                                  http://www.exoffice.com
Exoffice, The ExoLab Company             tel: (650) 259-9796

Mime
View raw message