You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2001/12/20 18:05:23 UTC

[vote] Removing namespace-prefixes feature on parsers

Hi team,

The default behaviour of a SAX parser when encountering an xmlns:xxx
namespace declaration is to call ContentHandler.startPrefixMapping(),
and to remove this attribute from the Attributes object passed to
startElemnt().

But Cocoon code also sets the "namespace-prefixes" feature each time it
creates a Parser. This has the effect of also passing xmlns:xxx in the
Attributes (see ContentHandler.startElement() javadocs for more
details).

What is the reason for enabling this feature ? I guess this was a try to
circumvent a long-standing (still present) bug in Xalan's serializer
which doesn't output properly namespace declarations if they're not
present as attributes in the incoming SAX stream. However, this wasn't
the solution and I patched several months ago AbstractTextSerializer to
make Xalan happy.

Now I'm using Saxon for some parts of our apps and this one barks on
each and every xmlns:xxx attribute it encounters when reading
stylesheets. So I locally removed the namespace-prefixes feature : this
fixes Saxon problems and doesn't hurt Xalan (it needs them only for
proper serialization).

So, team, what about not enabling the "namespace-prefix" feature and
thus keep the default behaviour of SAX parsers ?

+1 from me.

Sylvain.

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

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


Re: [vote] Removing namespace-prefixes feature on parsers

Posted by Berin Loritsch <bl...@apache.org>.
Vadim Gritsenko wrote:

> <snip/>
> 
>>>>What about making the parser configurable for this setting like
>>>>it is configurable regarding validation?
>>>>
>>>It is already configurable in PooledJaxpParser that I wrote to reuse
>>>parsers instead of just factories.
>>>
>>>I've been using it here for several weeks without problems. So I
>>>
> propose
> 
>>>to move PooledJaxpParser code to JaxpPaser and not set
>>>"namespace-prefixes" by default.
>>>
>>>
>>This would remove the PooledJaxpParser, right? (Or better deprecate?).
>>
> 
> Do we need to deprecate components which are not part of any release?
> 
> Or: Do we have backward compatibility between nightly builds? ;)


 From the Grand Poo-Bah himself:

;p  I couldn't resist :)

If the class has *ever* been released then it must be deprecated.  No
if, and, or buts about it.


Regarding Components that have never been released, you have to ask how
long it has been in the Cocoon heirarchy?  If it has been here for a
month, then I would deprecate it (like the DefaultComponentManager in
Excalibur).  You do have the freedom in this case to remove this
deprecated component *prior* to actually releasing the new Cocoon code.

The reason for this is simple:  someone may be working on a snapshot of
the Cocoon HEAD CVS repository.  In this case, it is simply remapping
a component in the Cocoon.xconf file.  However, when I wrote the deprecation
policy not only were components missing, but *functionality* was changed
to the point that the Component no longer worked as expected.  That is
the thing that we have to avoid at all costs!


> 
> Vadim
> 
> 
>>+1
>>
>>Carsten
>>
>>
> 
> <snip/>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> .
> 
> 



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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


RE: [vote] Removing namespace-prefixes feature on parsers

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote
> 
> <snip/>
> 
> > > >
> > > > What about making the parser configurable for this setting like
> > > > it is configurable regarding validation?
> > >
> > > It is already configurable in PooledJaxpParser that I wrote to reuse
> > > parsers instead of just factories.
> > >
> > > I've been using it here for several weeks without problems. So I
> propose
> > > to move PooledJaxpParser code to JaxpPaser and not set
> > > "namespace-prefixes" by default.
> > >
> > This would remove the PooledJaxpParser, right? (Or better deprecate?).
> 
> Do we need to deprecate components which are not part of any release?
> 
> Or: Do we have backward compatibility between nightly builds? ;)
> 
This is exactly why I asked the question. I personally would remove it
and not deprecate it as it was never part of any official release.

Carsten

> Vadim
> 
> > +1
> > 
> > Carsten
> > 
> 
> <snip/>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

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


RE: [vote] Removing namespace-prefixes feature on parsers

Posted by Vadim Gritsenko <va...@verizon.net>.
<snip/>

> > >
> > > What about making the parser configurable for this setting like
> > > it is configurable regarding validation?
> >
> > It is already configurable in PooledJaxpParser that I wrote to reuse
> > parsers instead of just factories.
> >
> > I've been using it here for several weeks without problems. So I
propose
> > to move PooledJaxpParser code to JaxpPaser and not set
> > "namespace-prefixes" by default.
> >
> This would remove the PooledJaxpParser, right? (Or better deprecate?).

Do we need to deprecate components which are not part of any release?

Or: Do we have backward compatibility between nightly builds? ;)

Vadim

> +1
> 
> Carsten
> 

<snip/>


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


RE: [vote] Removing namespace-prefixes feature on parsers

Posted by giacomo <gi...@apache.org>.
On Fri, 21 Dec 2001, Carsten Ziegeler wrote:

> Sylvain Wallez wrote:
> >
> > Carsten Ziegeler a écrit :
> > >
> > > Vadim Gritsenko wrote:
> > > >
> > > > I'm not a namespace guru... ;)
> > > > If this does not break anything, count me in: +1.
> > > Same applies here: +1
> > >
> > > What about making the parser configurable for this setting like
> > > it is configurable regarding validation?
> >
> > It is already configurable in PooledJaxpParser that I wrote to reuse
> > parsers instead of just factories.
> >
> > I've been using it here for several weeks without problems. So I propose
> > to move PooledJaxpParser code to JaxpPaser and not set
> > "namespace-prefixes" by default.
> >
> This would remove the PooledJaxpParser, right? (Or better deprecate?).

Hmm.. if we follow Berins proposal I think we should deprecate
PooledJaxpParser first.

+1

Giacomo

> +1
>
> Carsten
>
> > > Did you post this as a bug to SAXON?
> >
> > I'll do it.
> >
> > The Xalan bug is already identified, but marked as low priority :
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1831
> >
> > Sylvain.
> >
> > > Carsten
> > >
> > > >
> > > > Vadim
> > > >
> > > > > -----Original Message-----
> > > > > From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> > > > > Sent: Thursday, December 20, 2001 12:05 PM
> > > > > To: cocoon-dev
> > > > > Subject: [vote] Removing namespace-prefixes feature on parsers
> > > > >
> > > > > Hi team,
> > > > >
> > > > > The default behaviour of a SAX parser when encountering an xmlns:xxx
> > > > > namespace declaration is to call
> > ContentHandler.startPrefixMapping(),
> > > > > and to remove this attribute from the Attributes object passed to
> > > > > startElemnt().
> > > > >
> > > > > But Cocoon code also sets the "namespace-prefixes" feature each time
> > > > it
> > > > > creates a Parser. This has the effect of also passing
> > xmlns:xxx in the
> > > > > Attributes (see ContentHandler.startElement() javadocs for more
> > > > > details).
> > > > >
> > > > > What is the reason for enabling this feature ? I guess this
> > was a try
> > > > to
> > > > > circumvent a long-standing (still present) bug in Xalan's serializer
> > > > > which doesn't output properly namespace declarations if they're not
> > > > > present as attributes in the incoming SAX stream. However,
> > this wasn't
> > > > > the solution and I patched several months ago AbstractTextSerializer
> > > > to
> > > > > make Xalan happy.
> > > > >
> > > > > Now I'm using Saxon for some parts of our apps and this one barks on
> > > > > each and every xmlns:xxx attribute it encounters when reading
> > > > > stylesheets. So I locally removed the namespace-prefixes feature :
> > > > this
> > > > > fixes Saxon problems and doesn't hurt Xalan (it needs them only for
> > > > > proper serialization).
> > > > >
> > > > > So, team, what about not enabling the "namespace-prefix" feature and
> > > > > thus keep the default behaviour of SAX parsers ?
> > > > >
> > > > > +1 from me.
> > > > >
> > > > > Sylvain.
> >
> > --
> > Sylvain Wallez
> > Anyware Technologies - http://www.anyware-tech.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>


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


RE: [vote] Removing namespace-prefixes feature on parsers

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Carsten Ziegeler a écrit :
> >
> > Vadim Gritsenko wrote:
> > >
> > > I'm not a namespace guru... ;)
> > > If this does not break anything, count me in: +1.
> > Same applies here: +1
> >
> > What about making the parser configurable for this setting like
> > it is configurable regarding validation?
>
> It is already configurable in PooledJaxpParser that I wrote to reuse
> parsers instead of just factories.
>
> I've been using it here for several weeks without problems. So I propose
> to move PooledJaxpParser code to JaxpPaser and not set
> "namespace-prefixes" by default.
>
This would remove the PooledJaxpParser, right? (Or better deprecate?).
+1

Carsten

> > Did you post this as a bug to SAXON?
>
> I'll do it.
>
> The Xalan bug is already identified, but marked as low priority :
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1831
>
> Sylvain.
>
> > Carsten
> >
> > >
> > > Vadim
> > >
> > > > -----Original Message-----
> > > > From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> > > > Sent: Thursday, December 20, 2001 12:05 PM
> > > > To: cocoon-dev
> > > > Subject: [vote] Removing namespace-prefixes feature on parsers
> > > >
> > > > Hi team,
> > > >
> > > > The default behaviour of a SAX parser when encountering an xmlns:xxx
> > > > namespace declaration is to call
> ContentHandler.startPrefixMapping(),
> > > > and to remove this attribute from the Attributes object passed to
> > > > startElemnt().
> > > >
> > > > But Cocoon code also sets the "namespace-prefixes" feature each time
> > > it
> > > > creates a Parser. This has the effect of also passing
> xmlns:xxx in the
> > > > Attributes (see ContentHandler.startElement() javadocs for more
> > > > details).
> > > >
> > > > What is the reason for enabling this feature ? I guess this
> was a try
> > > to
> > > > circumvent a long-standing (still present) bug in Xalan's serializer
> > > > which doesn't output properly namespace declarations if they're not
> > > > present as attributes in the incoming SAX stream. However,
> this wasn't
> > > > the solution and I patched several months ago AbstractTextSerializer
> > > to
> > > > make Xalan happy.
> > > >
> > > > Now I'm using Saxon for some parts of our apps and this one barks on
> > > > each and every xmlns:xxx attribute it encounters when reading
> > > > stylesheets. So I locally removed the namespace-prefixes feature :
> > > this
> > > > fixes Saxon problems and doesn't hurt Xalan (it needs them only for
> > > > proper serialization).
> > > >
> > > > So, team, what about not enabling the "namespace-prefix" feature and
> > > > thus keep the default behaviour of SAX parsers ?
> > > >
> > > > +1 from me.
> > > >
> > > > Sylvain.
>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


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


Re: [vote] Removing namespace-prefixes feature on parsers

Posted by Sylvain Wallez <sy...@anyware-tech.com>.

Carsten Ziegeler a écrit :
> 
> Vadim Gritsenko wrote:
> >
> > I'm not a namespace guru... ;)
> > If this does not break anything, count me in: +1.
> Same applies here: +1
> 
> What about making the parser configurable for this setting like
> it is configurable regarding validation?

It is already configurable in PooledJaxpParser that I wrote to reuse
parsers instead of just factories.

I've been using it here for several weeks without problems. So I propose
to move PooledJaxpParser code to JaxpPaser and not set
"namespace-prefixes" by default.

> Did you post this as a bug to SAXON?

I'll do it.

The Xalan bug is already identified, but marked as low priority :
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1831

Sylvain.

> Carsten
> 
> >
> > Vadim
> >
> > > -----Original Message-----
> > > From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> > > Sent: Thursday, December 20, 2001 12:05 PM
> > > To: cocoon-dev
> > > Subject: [vote] Removing namespace-prefixes feature on parsers
> > >
> > > Hi team,
> > >
> > > The default behaviour of a SAX parser when encountering an xmlns:xxx
> > > namespace declaration is to call ContentHandler.startPrefixMapping(),
> > > and to remove this attribute from the Attributes object passed to
> > > startElemnt().
> > >
> > > But Cocoon code also sets the "namespace-prefixes" feature each time
> > it
> > > creates a Parser. This has the effect of also passing xmlns:xxx in the
> > > Attributes (see ContentHandler.startElement() javadocs for more
> > > details).
> > >
> > > What is the reason for enabling this feature ? I guess this was a try
> > to
> > > circumvent a long-standing (still present) bug in Xalan's serializer
> > > which doesn't output properly namespace declarations if they're not
> > > present as attributes in the incoming SAX stream. However, this wasn't
> > > the solution and I patched several months ago AbstractTextSerializer
> > to
> > > make Xalan happy.
> > >
> > > Now I'm using Saxon for some parts of our apps and this one barks on
> > > each and every xmlns:xxx attribute it encounters when reading
> > > stylesheets. So I locally removed the namespace-prefixes feature :
> > this
> > > fixes Saxon problems and doesn't hurt Xalan (it needs them only for
> > > proper serialization).
> > >
> > > So, team, what about not enabling the "namespace-prefix" feature and
> > > thus keep the default behaviour of SAX parsers ?
> > >
> > > +1 from me.
> > >
> > > Sylvain.

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

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


RE: [vote] Removing namespace-prefixes feature on parsers

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
> 
> I'm not a namespace guru... ;)
> If this does not break anything, count me in: +1.
Same applies here: +1

What about making the parser configurable for this setting like
it is configurable regarding validation?
Did you post this as a bug to SAXON?

Carsten

> 
> Vadim
> 
> > -----Original Message-----
> > From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> > Sent: Thursday, December 20, 2001 12:05 PM
> > To: cocoon-dev
> > Subject: [vote] Removing namespace-prefixes feature on parsers
> > 
> > Hi team,
> > 
> > The default behaviour of a SAX parser when encountering an xmlns:xxx
> > namespace declaration is to call ContentHandler.startPrefixMapping(),
> > and to remove this attribute from the Attributes object passed to
> > startElemnt().
> > 
> > But Cocoon code also sets the "namespace-prefixes" feature each time
> it
> > creates a Parser. This has the effect of also passing xmlns:xxx in the
> > Attributes (see ContentHandler.startElement() javadocs for more
> > details).
> > 
> > What is the reason for enabling this feature ? I guess this was a try
> to
> > circumvent a long-standing (still present) bug in Xalan's serializer
> > which doesn't output properly namespace declarations if they're not
> > present as attributes in the incoming SAX stream. However, this wasn't
> > the solution and I patched several months ago AbstractTextSerializer
> to
> > make Xalan happy.
> > 
> > Now I'm using Saxon for some parts of our apps and this one barks on
> > each and every xmlns:xxx attribute it encounters when reading
> > stylesheets. So I locally removed the namespace-prefixes feature :
> this
> > fixes Saxon problems and doesn't hurt Xalan (it needs them only for
> > proper serialization).
> > 
> > So, team, what about not enabling the "namespace-prefix" feature and
> > thus keep the default behaviour of SAX parsers ?
> > 
> > +1 from me.
> > 
> > Sylvain.
> > 
> > --
> > Sylvain Wallez
> > Anyware Technologies - http://www.anyware-tech.com
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

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


RE: [vote] Removing namespace-prefixes feature on parsers

Posted by Vadim Gritsenko <va...@verizon.net>.
I'm not a namespace guru... ;)
If this does not break anything, count me in: +1.

Vadim

> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> Sent: Thursday, December 20, 2001 12:05 PM
> To: cocoon-dev
> Subject: [vote] Removing namespace-prefixes feature on parsers
> 
> Hi team,
> 
> The default behaviour of a SAX parser when encountering an xmlns:xxx
> namespace declaration is to call ContentHandler.startPrefixMapping(),
> and to remove this attribute from the Attributes object passed to
> startElemnt().
> 
> But Cocoon code also sets the "namespace-prefixes" feature each time
it
> creates a Parser. This has the effect of also passing xmlns:xxx in the
> Attributes (see ContentHandler.startElement() javadocs for more
> details).
> 
> What is the reason for enabling this feature ? I guess this was a try
to
> circumvent a long-standing (still present) bug in Xalan's serializer
> which doesn't output properly namespace declarations if they're not
> present as attributes in the incoming SAX stream. However, this wasn't
> the solution and I patched several months ago AbstractTextSerializer
to
> make Xalan happy.
> 
> Now I'm using Saxon for some parts of our apps and this one barks on
> each and every xmlns:xxx attribute it encounters when reading
> stylesheets. So I locally removed the namespace-prefixes feature :
this
> fixes Saxon problems and doesn't hurt Xalan (it needs them only for
> proper serialization).
> 
> So, team, what about not enabling the "namespace-prefix" feature and
> thus keep the default behaviour of SAX parsers ?
> 
> +1 from me.
> 
> Sylvain.
> 
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
> 


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