You are viewing a plain text version of this content. The canonical link for it is here.
Posted to axkit-dev@xml.apache.org by Michael A Nachbaur <mi...@nachbaur.com> on 2004/07/19 07:00:19 UTC

AxXMLCatalog, Reloaded...

Hi Dahuts and AxKittens.

I sent a message a while back about my AxXMLCatalog patch, but just in case 
you may not remember it or have it in your mail box, I'm attaching it here 
again.

I'd like to apply this to CVS soon, so if anyone has any comments, please let 
me know.

Essentially, this patch intends to add the "AxXMLCatalog" Apache directive 
which defines which XML catalogs to include into XML::LibXML.

-- 
Michael A. Nachbaur <mi...@nachbaur.com>
http://nachbaur.com/pgpkey.asc



Re: AxXMLCatalog, Reloaded...

Posted by Michael A Nachbaur <mi...@nachbaur.com>.
On July 19, 2004 02:17 am, Robin Berjon wrote:
> Dahut Nacho!

Dahut Darobin!

> > +sub XMLCatalogs {
> > +    my $self = shift;
> > +
> > +    my @others;
> > +
> > +    print STDERR "XML Catalog: ", join(", ", %{
> > $self->{cfg}{XMLCatalogs} } ), "\n";
>
> You might want to drop that line :) (and why not use warn instead?).

:-)  Yeah, I noticed that just after I sent it.  Oops.

> > +=head2 AxXMLCatalog
> > +
> > +Use this directive to add additional XML catalogs to the XML
> > transformation +engine.  XML Catalogs provide an interoperable way to map
> > information about +an XML resource to a URI reference.  This enables you
> > to, among other things, +define custom URIs representing files or
> > sections of your site, making +references to such resources more
> > portable.
> > +
> > +    AxXMLCatalog /catalog.xml
>
> Reading this it's unclear to me whether that path is from the docroot
> (as most Apache configuration parameters are) or if it's from the FS
> root (as one often specifies catalogs).
>
> Apart from that, it looks perfect :)

Okay, I'll mention how its relative to the docroot in there.

Any feedback, or +/- 1s from anyone else?

-- 
Michael A. Nachbaur <mi...@nachbaur.com>
http://nachbaur.com/pgpkey.asc

Re: AxXMLCatalog, Reloaded...

Posted by Robin Berjon <ro...@expway.fr>.
Dahut Nacho!

Michael A Nachbaur wrote:
> Essentially, this patch intends to add the "AxXMLCatalog" Apache directive 
> which defines which XML catalogs to include into XML::LibXML.

I think this is a useful and valuable thing to add. Just a few comments.

> +sub XMLCatalogs {
> +    my $self = shift;
> +    
> +    my @others;
> +    
> +    print STDERR "XML Catalog: ", join(", ", %{ $self->{cfg}{XMLCatalogs} } ), "\n";

You might want to drop that line :) (and why not use warn instead?).

> +=head2 AxXMLCatalog
> +
> +Use this directive to add additional XML catalogs to the XML transformation
> +engine.  XML Catalogs provide an interoperable way to map information about
> +an XML resource to a URI reference.  This enables you to, among other things,
> +define custom URIs representing files or sections of your site, making
> +references to such resources more portable.
> +
> +    AxXMLCatalog /catalog.xml

Reading this it's unclear to me whether that path is from the docroot 
(as most Apache configuration parameters are) or if it's from the FS 
root (as one often specifies catalogs).

Apart from that, it looks perfect :)

-- 
Robin Berjon

Re: AxXMLCatalog, Reloaded...

Posted by Robin Berjon <ro...@expway.fr>.
Michael A Nachbaur wrote:
> That isn't a bad idea.  I've wanted for a while to take advantage of 
> XML::LibXML's various configuration parameters, but have been reluctant to do 
> so since I don't want to have an Ax* directive problem...but the XML catalogs 
> bit was just too desirable to let be.
> 
> So, if this is the direction everyone'd like to go (anyone?) the XML Catalog 
> directive would look like so:
> 
> AxXMLParserOpt XMLCatalog /catalog1.xml
> AxXMLParserOpt XMLCatalog /catalog2.xml
> AxXMLParserOpt MaxDepth 4500
> etc...

+1

-- 
Robin Berjon

Re: AxXMLCatalog, Reloaded...

Posted by Michael A Nachbaur <mi...@nachbaur.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On July 19, 2004 09:34 am, Michael A Nachbaur wrote:
> On July 19, 2004 08:29 am, Kip Hampton wrote:
> > Michael A Nachbaur wrote:
> > > Essentially, this patch intends to add the "AxXMLCatalog" Apache
> > > directive which defines which XML catalogs to include into XML::LibXML.
> >
> > Might we not be better off creating a more generic AxXMLParserOpt
> > directive (that pushes onto a @list of key/value pairs)?
<snip>
> So, if this is the direction everyone'd like to go (anyone?) the XML
> Catalog directive would look like so:
>
> AxXMLParserOpt XMLCatalog /catalog1.xml
> AxXMLParserOpt XMLCatalog /catalog2.xml
> AxXMLParserOpt MaxDepth 4500

I had hoped to finish this sometime earlier this week, but it doesn't look 
like thats going to happen.  I'll get back to it, and will check it in 
(complete with the new syntax and Apache::Test testcases) after OSCon.

- -- 
Michael A. Nachbaur <mi...@nachbaur.com>
http://nachbaur.com/pgpkey.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBAE68vow0fXaFDZQRArBCAJ9ljy8uBznAkHkqA33TcVfgrL4PRwCeIelB
O3HGF+kRh7OmmzLOMfjVXj4=
=86bB
-----END PGP SIGNATURE-----

Re: AxXMLCatalog, Reloaded...

Posted by Kip Hampton <kh...@totalcinema.com>.
Michael A Nachbaur wrote:

> 
> So, if this is the direction everyone'd like to go (anyone?) the XML Catalog 
> directive would look like so:
> 
> AxXMLParserOpt XMLCatalog /catalog1.xml
> AxXMLParserOpt XMLCatalog /catalog2.xml
> AxXMLParserOpt MaxDepth 4500
> etc...

+1

Re: AxXMLCatalog, Reloaded...

Posted by Michael A Nachbaur <mi...@nachbaur.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On July 19, 2004 08:29 am, Kip Hampton wrote:
> Michael A Nachbaur wrote:
> > Essentially, this patch intends to add the "AxXMLCatalog" Apache
> > directive which defines which XML catalogs to include into XML::LibXML.
>
> Might we not be better off creating a more generic AxXMLParserOpt
> directive (that pushes onto a @list of key/value pairs)?

That isn't a bad idea.  I've wanted for a while to take advantage of 
XML::LibXML's various configuration parameters, but have been reluctant to do 
so since I don't want to have an Ax* directive problem...but the XML catalogs 
bit was just too desirable to let be.

So, if this is the direction everyone'd like to go (anyone?) the XML Catalog 
directive would look like so:

AxXMLParserOpt XMLCatalog /catalog1.xml
AxXMLParserOpt XMLCatalog /catalog2.xml
AxXMLParserOpt MaxDepth 4500
etc...

> Rationale: We already suffer from too many conf directives-- this adds
> an important one-- but there are many others that people might want
> access to as well. Do we really want to duplicate Ax* option for each
> possible parser option? The answer is an obvious "no" but, then how do
> we decide which ones to support/leave out?

Might this be useful as well for instances like the recent 
XML::LibXSLT->max_depth discussion on the perl-xml mailing list?

> Also, what if I'm not using XML::LibXML, is this option still relevant?
> Aren't we setting ourselves up to create still more Ax* options for the
> other parsers?

Well, if another parser supports XML catalogs, presumably this same directive 
could be used for it as well.  Its been such a long time since I played with 
Sablotron that it shouldn't even be considered as valid experience any more, 
so I'm not certain if it can use catalogs.

- -- 
Michael A. Nachbaur <mi...@nachbaur.com>
http://nachbaur.com/pgpkey.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA+/g0vow0fXaFDZQRAm+6AJ9HHoTgWsvhyWGRzg4ih+MlsfiDuACeIT6W
d72RpWp+X541ts/d4AC9Fo0=
=c73v
-----END PGP SIGNATURE-----

Re: AxXMLCatalog, Reloaded...

Posted by Kip Hampton <kh...@totalcinema.com>.
Michael A Nachbaur wrote:

> Essentially, this patch intends to add the "AxXMLCatalog" Apache directive 
> which defines which XML catalogs to include into XML::LibXML.
> 

Might we not be better off creating a more generic AxXMLParserOpt 
directive (that pushes onto a @list of key/value pairs)?

Rationale: We already suffer from too many conf directives-- this adds 
an important one-- but there are many others that people might want 
access to as well. Do we really want to duplicate Ax* option for each 
possible parser option? The answer is an obvious "no" but, then how do 
we decide which ones to support/leave out?

Also, what if I'm not using XML::LibXML, is this option still relevant? 
Aren't we setting ourselves up to create still more Ax* options for the 
other parsers?

-kip