Looking for python compliant NXDs

Date: Tue, 19 Feb 2002 14:51:39 = +0100

 tags to prevent line breaks, which works for the code but makes the
rest of the page nearly unusable.  This is made worse by:

2) The fonts are too large and are fixed in size by the css.  So I can't
make them display smaller (well, I can with Opera but that's the only
browser that can demagnify).  I urge you to change the font specification to
use relative sizes (e.g., {font-size:110%}), and use smaller font sizes in
the  elements (say 80%).  This way the user will be able to change the
size of the display.   The way it is probably looks fine on a 21 in monitor
using 1280 resolution, but everyone doesn't have one.

Cheers,

Tom P

From mal@lemburg.com  Thu Feb 21 14:29:51 2002
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 21 Feb 2002 15:29:51 +0100
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
References: <20020221073820.T25311@redhat.com> <3C74F599.7CBFFD10@lemburg.com> <20020221084705.U25311@redhat.com>
Message-ID: <3C75045F.1B0702E6@lemburg.com>

Daniel Veillard wrote:
> 
> On Thu, Feb 21, 2002 at 02:26:49PM +0100, M.-A. Lemburg wrote:
> > I've downloaded both the libxml2 and libxslt libs, but it's
> > not clear to me where to find the Python extensions (there's
> > some mention of them in libxslt, but nothing in libxml2).
> 
>   In the python subdir in the source tree

I found that only in libxslt... not in libxml2. Am I missing
something, or is this intended ?

> > Ideal would be to have them as distutils setup.py style
> > packages, so that it is possible to install them without
> > having to compile the libs themselves.
> 
>   Hum, a lot of them are actually generated, and then need
> some preprocessing, the stubs for example are not part of the
> archives (but build with a python script). This would basically
> amount to rewrite the python/Makefile.am with a different facility.
> The key point is that I'm not used to setup.py, it must have
> some knowledge of the C compiler flags for shared libs, the path
> to python binaries and associated paths, etc... Can you share a
> pointer describing this ?

It's all here:

	http://www.python.org/sigs/distutils-sig/doc/

Note that distutils has its own way of finding the Python
paths.

Providing paths to various files needed from libxml2/xslt
can be done by either automatic lookup or customizing 
the build_ext command.

If you can provide the readily built .c and .h files,
it should be no problem creating a setup.py files which
then does the rest.

If you need help, just ask (preferrably on the 
distutils-sig or me directly).

> > Also, I'm a little unsure how the David Kuhlman Python
> > extensions fit into the picture: are they no longer needed
> > or do they provide extra functionality ?
> 
>    They are not needed, I learned from David's binding but
> the bindings are very different. Mine are automatically generated
> from a strict definition of the libraries APIs (with a bit of glue
> of course).

Ok.

One other thing which I couldn't find on the web-site:
what licenses are imposed on libxml2/xslt and the Python
bindings.

The .tar.gz files contain the GPL COPYING file and
the LGPL COPYING.LIB file but the various other
(source) files don't mention any license at all
and the README also points to a W3C license... a bit
confusing :-)

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/

From walter@livinglogic.de  Thu Feb 21 14:32:29 2002
From: walter@livinglogic.de (Walter =?ISO-8859-1?Q?D=F6rwald?=)
Date: Thu, 21 Feb 2002 15:32:29 +0100
Subject: [XML-SIG] Re: Ideas for web/ package
References: <200202202225.RAA137368@spool6.valueweb.net> <3C74ADC5.7D99F866@lemburg.com> <3C74F2E1.1010703@livinglogic.de> <3C74F734.17F3BB93@lemburg.com>
Message-ID: <3C7504FD.4080202@livinglogic.de>

M.-A. Lemburg wrote:

> Walter D鰎wald wrote:
> 
>>M.-A. Lemburg wrote:
>> > Seriously, mxURL will slowly move towards RFC 2396 and
>> > so the answer is "yes, but...".
>>
>>What I'd like to have is an RFC2396 compliant URL class,
>>that has all the url components as assignable properties,
>>...
>>
> 
> mxURL provides an immutable type, so assigment to attributes
> is not possible. However, you can use an existing URL object
> to construct a new one out of it: the .rebuild() method
> allows to do this.

Yes, but instead of extracting the components I want to keep from
the old URL and stuff them back into a new URL, I find it simpler
to simple change the URL object in place, especially when it's
possible to change the object on any level.

> Something I might add in the future is support for what
> you've called path_segments (with the possibility to assign
> parameters to all path segments, not just the last one as
> is currently implemented in mxURL). I've never actually seen 
> it in use on web-pages and didn't even know about this
> possibility when I wrote mxURL.

It's part of RFC2396.

The terminology has slightly changed too: e.g. netloc has
changed to authority etc.

Bye,
    Walter D鰎wald

-- 
Walter D鰎wald � LivingLogic AG, Bayreuth/Germany � www.livinglogic.de

From veillard@redhat.com  Thu Feb 21 14:35:07 2002
From: veillard@redhat.com (Daniel Veillard)
Date: Thu, 21 Feb 2002 09:35:07 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <000c01c1badf$741f0d70$0bf13044@tbp>; from tpassin@comcast.net on Thu, Feb 21, 2002 at 08:55:42AM -0500
References: <20020221073820.T25311@redhat.com> <000c01c1badf$741f0d70$0bf13044@tbp>
Message-ID: <20020221093507.V25311@redhat.com>

On Thu, Feb 21, 2002 at 08:55:42AM -0500, Thomas B. Passin wrote:
> [Daniel Veillard]
> 
> Love the work

  thanks,

> but hate the web site:

  Arghh, sorry if we get off-topic there :-\

> 1) Pages with code like http://xmlsoft.org/python.html do not wrap, making
> them extremely annoying to read.  They don't wrap because the code is in
>  tags to prevent line breaks, which works for the code but makes the
> rest of the page nearly unusable.  This is made worse by:

  Any alternative to pre ? Code doesn't do it, width on pre seems
to get ignore and code with "white-space: pre" gives the same result for me.

> 2) The fonts are too large and are fixed in size by the css.  So I can't
> make them display smaller (well, I can with Opera but that's the only
> browser that can demagnify).

   Galeon provides that too.

> I urge you to change the font specification to
> use relative sizes (e.g., {font-size:110%}), and use smaller font sizes in
> the  elements (say 80%).  This way the user will be able to change the
> size of the display.   The way it is probably looks fine on a 21 in monitor
> using 1280 resolution, but everyone doesn't have one.

   Hum, each time I touch those CSS settings somemeone complains I 
should fix them in a different way... the good point is that I just need
to change them in the XSLT to fix the whole site:

------------------------
TD {font-size: 14pt; font-family: Verdana,Arial,Helvetica}
BODY {font-size: 14pt; font-family: Verdana,Arial,Helvetica; margin-top: 2em; margin-left: 0em; margin-right: 0em}
H1 {font-size: 20pt; font-family: Verdana,Arial,Helvetica}
H2 {font-size: 18pt; font-family: Verdana,Arial,Helvetica}
H3 {font-size: 16pt; font-family: Verdana,Arial,Helvetica}
------------------------

  Is removing all the font-size properties sufficient ?
I tried and it looks acceptable to me in term of size. But doesn't fix
the fact that  extends too much.
  What do you suggest ?

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

From veillard@redhat.com  Thu Feb 21 14:40:42 2002
From: veillard@redhat.com (Daniel Veillard)
Date: Thu, 21 Feb 2002 09:40:42 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <3C75045F.1B0702E6@lemburg.com>; from mal@lemburg.com on Thu, Feb 21, 2002 at 03:29:51PM +0100
References: <20020221073820.T25311@redhat.com> <3C74F599.7CBFFD10@lemburg.com> <20020221084705.U25311@redhat.com> <3C75045F.1B0702E6@lemburg.com>
Message-ID: <20020221094042.W25311@redhat.com>

On Thu, Feb 21, 2002 at 03:29:51PM +0100, M.-A. Lemburg wrote:
> Daniel Veillard wrote:
> > 
> > On Thu, Feb 21, 2002 at 02:26:49PM +0100, M.-A. Lemburg wrote:
> > > I've downloaded both the libxml2 and libxslt libs, but it's
> > > not clear to me where to find the Python extensions (there's
> > > some mention of them in libxslt, but nothing in libxml2).
> > 
> >   In the python subdir in the source tree
> 
> I found that only in libxslt... not in libxml2. Am I missing
> something, or is this intended ?

  Seems you need to get a recent libxml2 release. 2.4.16 for example
ftp://xmlsoft.org/

> It's all here:
> 
> 	http://www.python.org/sigs/distutils-sig/doc/
> 
> Note that distutils has its own way of finding the Python
> paths.
> 
> Providing paths to various files needed from libxml2/xslt
> can be done by either automatic lookup or customizing 
> the build_ext command.
> 
> If you can provide the readily built .c and .h files,
> it should be no problem creating a setup.py files which
> then does the rest.
> 
> If you need help, just ask (preferrably on the 
> distutils-sig or me directly).

  Okay I will look at it and contact off-line of needed.

> One other thing which I couldn't find on the web-site:
> what licenses are imposed on libxml2/xslt and the Python
> bindings.
> 
> The .tar.gz files contain the GPL COPYING file and
> the LGPL COPYING.LIB file but the various other
> (source) files don't mention any license at all
> and the README also points to a W3C license... a bit
> confusing :-)

  Fixed.
  Look at the recent releases, and the web pages. Everything has
be switched under the MIT Licence in 2.4.14/1.0.11
    http://xmlsoft.org/news.html
    http://xmlsoft.org/XSLT/news.html

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

From mal@lemburg.com  Thu Feb 21 14:45:30 2002
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 21 Feb 2002 15:45:30 +0100
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
References: <20020221073820.T25311@redhat.com> <3C74F599.7CBFFD10@lemburg.com> <20020221084705.U25311@redhat.com> <3C75045F.1B0702E6@lemburg.com> <20020221094042.W25311@redhat.com>
Message-ID: <3C75080A.20BB591D@lemburg.com>

Daniel Veillard wrote:
> 
> > I found that only in libxslt... not in libxml2. Am I missing
> > something, or is this intended ?
> 
>   Seems you need to get a recent libxml2 release. 2.4.16 for example
> ftp://xmlsoft.org/

Ah, thanks... I had 2.4.9.

> > It's all here:
> >
> >       http://www.python.org/sigs/distutils-sig/doc/
> >
> > Note that distutils has its own way of finding the Python
> > paths.
> >
> > Providing paths to various files needed from libxml2/xslt
> > can be done by either automatic lookup or customizing
> > the build_ext command.
> >
> > If you can provide the readily built .c and .h files,
> > it should be no problem creating a setup.py files which
> > then does the rest.
> >
> > If you need help, just ask (preferrably on the
> > distutils-sig or me directly).
> 
>   Okay I will look at it and contact off-line of needed.
> 
> > One other thing which I couldn't find on the web-site:
> > what licenses are imposed on libxml2/xslt and the Python
> > bindings.
> >
> > The .tar.gz files contain the GPL COPYING file and
> > the LGPL COPYING.LIB file but the various other
> > (source) files don't mention any license at all
> > and the README also points to a W3C license... a bit
> > confusing :-)
> 
>   Fixed.
>   Look at the recent releases, and the web pages. Everything has
> be switched under the MIT Licence in 2.4.14/1.0.11
>     http://xmlsoft.org/news.html
>     http://xmlsoft.org/XSLT/news.html

That'll make things a lot easier. Thanks !

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/

From tpassin@comcast.net  Thu Feb 21 15:02:13 2002
From: tpassin@comcast.net (Thomas B. Passin)
Date: Thu, 21 Feb 2002 10:02:13 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
References: <20020221073820.T25311@redhat.com>
 <000c01c1badf$741f0d70$0bf13044@tbp> <20020221093507.V25311@redhat.com>
Message-ID: <005801c1bae8$bef74660$0bf13044@tbp>

[Daniel Veillard]

>    Hum, each time I touch those CSS settings somemeone complains I
> should fix them in a different way... the good point is that I just need
> to change them in the XSLT to fix the whole site:
>
> ------------------------
> TD {font-size: 14pt; font-family: Verdana,Arial,Helvetica}
> BODY {font-size: 14pt; font-family: Verdana,Arial,Helvetica; margin-top:
2em; margin-left: 0em; margin-right: 0em}
> H1 {font-size: 20pt; font-family: Verdana,Arial,Helvetica}
> H2 {font-size: 18pt; font-family: Verdana,Arial,Helvetica}
> H3 {font-size: 16pt; font-family: Verdana,Arial,Helvetica}
> ------------------------
>
>   Is removing all the font-size properties sufficient ?
> I tried and it looks acceptable to me in term of size. But doesn't fix
> the fact that  extends too much.
>   What do you suggest ?
>

Well, it **is** hard with  code lines.  I'd try to

1) edit the code by hand to insert line breaks where possible (as in line
continuations possible with some languages),

2) not use  but use arial, sans-serif,  or some other non-monospaced
font, because more characters will fit on a line and still be readable
(non-traditional but often helpful),

3) Use font-size:80% for code, especially if you stick with  after all.
If it's too small for some, they can increase the font viewing size or copy
and paste it into an editor, but the rest of the page will be usable.  I
have generally found that 80% is a good compromise between readability of
code and length of line.  The rest of the page could be 90% or 100%.

 70% often displays badly and is hard to read, and that might be worse on a
unix system without font smoothing (compared to Windows, I mean).

Bear in mind, too, that Courier font usually looks larger for the same point
size than most other fonts on the system, so it's more feasible to specify a
smaller size for it.

Another reason to use relative font sizes is to allow people with visual
impairments to be able to adjust the display so they can read it.

Your site isn't the only one. The Zope site, for example, has a lot of pages
with this problem too.

Thanks for being willing to tackle this.

Cheers,

Tom P

From uche.ogbuji@fourthought.com  Thu Feb 21 15:02:46 2002
From: uche.ogbuji@fourthought.com (Uche Ogbuji)
Date: Thu, 21 Feb 2002 08:02:46 -0700
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: Message from Daniel Veillard 
 of "Thu, 21 Feb 2002 07:38:20 EST." <20020221073820.T25311@redhat.com>
Message-ID: <200202211502.g1LF2kD03794@localhost.localdomain>

> I don't know how this could fit in the xml-sig framework, but they are now
> available as part of the libxml2 and libxslt releases. More informations
> and small tutorial/examples at:
>    http://xmlsoft.org/python.html
>    and
>    http://xmlsoft.org/XSLT/python.html
> 
> You will notice how XPath and XSLT engines can be extended with functions
> written in Python.
> Of course the Python bindings inherit from the speed and strict adherence
> to the associated standard which are the key points of the underlying C
> libraries. The libxml2 conformance against the OASIS XML test suite is 
> actually written as a Python script using the libxml2 module.

I think we should have as many tools as makes sense in PyXML.  My main 
question would be: what else do people need to have besides what is bundled in 
PyXML?  I assume libxml and the like, which is probably too much.

Either way, I'd be happy to update the XML-SIG XML topic to mention it.

Thanks a bunch for this.

-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Boulder, CO 80301-2537, USA
XML strategy, XML tools (http://4Suite.org), knowledge management

From veillard@redhat.com  Thu Feb 21 15:17:39 2002
From: veillard@redhat.com (Daniel Veillard)
Date: Thu, 21 Feb 2002 10:17:39 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <200202211502.g1LF2kD03794@localhost.localdomain>; from uche.ogbuji@fourthought.com on Thu, Feb 21, 2002 at 08:02:46AM -0700
References:  <200202211502.g1LF2kD03794@localhost.localdomain>
Message-ID: <20020221101738.X25311@redhat.com>

On Thu, Feb 21, 2002 at 08:02:46AM -0700, Uche Ogbuji wrote:
> I think we should have as many tools as makes sense in PyXML.  My main 
> question would be: what else do people need to have besides what is bundled in 
> PyXML?  I assume libxml and the like, which is probably too much.

  yup. I have been (mostly silently) following that list for the last month
and it is clear that libxml2/libxslt is in a large part redundant. On the
other hand I needed good Python bindings which would work with python 1.5
even if ancient. My set of APIs is huge (800+ functions) and covers
quite a bit more than just XML, half of them are available at the Python
level (not all types have wrappers), it was built as an independant subsystem
hence the relatively large scope.

> Either way, I'd be happy to update the XML-SIG XML topic to mention it.

  thanks, if you think it's on-topic.

> Thanks a bunch for this.

  You're welcome,

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

From fdrake@acm.org  Thu Feb 21 15:25:44 2002
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 21 Feb 2002 10:25:44 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <005801c1bae8$bef74660$0bf13044@tbp>
References: <20020221073820.T25311@redhat.com>
 <000c01c1badf$741f0d70$0bf13044@tbp>
 <20020221093507.V25311@redhat.com>
 <005801c1bae8$bef74660$0bf13044@tbp>
Message-ID: <15477.4472.183877.847307@grendel.zope.com>

[Daniel Veillard]
 >    Hum, each time I touch those CSS settings somemeone complains I
 > should fix them in a different way... the good point is that I just need

That's what users are for!  ;-)

Thomas B. Passin writes:
 > 1) edit the code by hand to insert line breaks where possible (as in line
 > continuations possible with some languages),

I only see one long code line on the page, and I wouldn't use a
continuation line to change it.  I'd use something like:

reference = ("startDocument:startElement foo {'url': 'tst'}:"
             "characters: bar:endElement foo:endDocument:")

 > 2) not use  but use arial, sans-serif,  or some other non-monospaced
 > font, because more characters will fit on a line and still be readable
 > (non-traditional but often helpful),

We tried this for the Python documentation, and the reaction was very
mixed.  If all instances of the selected element/class are purely code
examples, you'll probably be OK.  (For the Python docs, what
definately killed the idea was that we use the same element/class to
display interactive sessions, and changing that would be a *lot* of
tedious work, just to end up with inconsistent displays.)

 > Your site isn't the only one. The Zope site, for example, has a lot of pages
 > with this problem too.

I'd say something here, but then I'd get tasked with fixing it.  ;-(
Many of us are aware of the problem, but generally not those of us who
write the stylesheets.

  -Fred

-- 
Fred L. Drake, Jr.  
PythonLabs at Zope Corporation

From veillard@redhat.com  Thu Feb 21 16:06:28 2002
From: veillard@redhat.com (Daniel Veillard)
Date: Thu, 21 Feb 2002 11:06:28 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <15477.4472.183877.847307@grendel.zope.com>; from fdrake@acm.org on Thu, Feb 21, 2002 at 10:25:44AM -0500
References: <20020221073820.T25311@redhat.com> <000c01c1badf$741f0d70$0bf13044@tbp> <20020221093507.V25311@redhat.com> <005801c1bae8$bef74660$0bf13044@tbp> <15477.4472.183877.847307@grendel.zope.com>
Message-ID: <20020221110628.Z25311@redhat.com>

On Thu, Feb 21, 2002 at 10:25:44AM -0500, Fred L. Drake, Jr. wrote:
> 
> [Daniel Veillard]
>  >    Hum, each time I touch those CSS settings somemeone complains I
>  > should fix them in a different way... the good point is that I just need
> 
> That's what users are for!  ;-)

  hehe

> I only see one long code line on the page, and I wouldn't use a
> continuation line to change it.  I'd use something like:
> 
> reference = ("startDocument:startElement foo {'url': 'tst'}:"
>              "characters: bar:endElement foo:endDocument:")

  Bingoooo !

  http://xmlsoft.org/XSLT/python.html 
  should be fixed too now :-)

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

From fdrake@acm.org  Thu Feb 21 16:15:23 2002
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 21 Feb 2002 11:15:23 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <20020221110628.Z25311@redhat.com>
References: <20020221073820.T25311@redhat.com>
 <000c01c1badf$741f0d70$0bf13044@tbp>
 <20020221093507.V25311@redhat.com>
 <005801c1bae8$bef74660$0bf13044@tbp>
 <15477.4472.183877.847307@grendel.zope.com>
 <20020221110628.Z25311@redhat.com>
Message-ID: <15477.7451.907137.148448@grendel.zope.com>

I suggested:
 > reference = ("startDocument:startElement foo {'url': 'tst'}:"
 >              "characters: bar:endElement foo:endDocument:")

Daniel Veillard writes:
 >   Bingoooo !

It appears that the parentheses and indentation on the second line of
the expression got lost:

reference = "startDocument:startElement foo {'url': 'tst'}:"
"characters: bar:endElement foo:endDocument:"

is legal Python, but probably not what you intended.  ;)

 >   http://xmlsoft.org/XSLT/python.html 
 >   should be fixed too now :-)

These are looking much better; thanks!  (When the horizontal scrollbar
appears on Mozilla, and the window is maximized on a 1400x1050 screen,
something is definately wrong!  The scrollbar is gone now.)

  -Fred

-- 
Fred L. Drake, Jr.  
PythonLabs at Zope Corporation

From fdrake@acm.org  Thu Feb 21 16:36:14 2002
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 21 Feb 2002 11:36:14 -0500
Subject: [XML-SIG] regression testing framework
Message-ID: <15477.8702.115184.918167@grendel.zope.com>

Is anyone working on updating the regression testing framework based
on what's currently in Python?  For output-based tests, we'd gain
ndiff-style comparison of the actual and expected output, which would
be a huge improvement.

If no one is currently working on this (or at least considering it),
does anyone have any objections?

  -Fred

-- 
Fred L. Drake, Jr.  
PythonLabs at Zope Corporation

From zeroone@worldonline.co.za  Thu Feb 21 17:06:59 2002
From: zeroone@worldonline.co.za (Sean Allen)
Date: 21 Feb 2002 09:06:59 -0800
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <000c01c1badf$741f0d70$0bf13044@tbp>
References: <20020221073820.T25311@redhat.com>
 <000c01c1badf$741f0d70$0bf13044@tbp>
Message-ID: <1014311220.2321.44.camel@linux.zeroone.nowhere>

--=-34xmgJs/W+48f/YMjq9v
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2002-02-21 at 05:55, Thomas B. Passin wrote:
> [Daniel Veillard]
>=20
> Love the work but hate the web site:
>=20
> 1) Pages with code like http://xmlsoft.org/python.html do not wrap,=20
They do with Galeon 1.0.3 (i.e. Gecko) on Linux
>=20
> 2) The fonts are too large and are fixed in size by the css.  So I can't
> make them display smaller (well, I can with Opera but that's the only
> browser that can demagnify).=20
Galeon 1.0.3 (i.e. Gecko) on Linux.

I have no problems viewing this site straight out of the box so to
speak.

Sean Allen.

--=-34xmgJs/W+48f/YMjq9v
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA8dSkzoo+D8xwsOTIRAvs7AJ9KsSSjc6bAaG3YFNHmKIPVmFJI+QCbBHRc
ibHlGFeuiANaMDFR8BApaws=
=EeWK
-----END PGP SIGNATURE-----

--=-34xmgJs/W+48f/YMjq9v--

From martin@v.loewis.de  Thu Feb 21 17:15:04 2002
From: martin@v.loewis.de (Martin v. Loewis)
Date: 21 Feb 2002 18:15:04 +0100
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <200202211502.g1LF2kD03794@localhost.localdomain>
References: <200202211502.g1LF2kD03794@localhost.localdomain>
Message-ID: 

Uche Ogbuji  writes:

> Either way, I'd be happy to update the XML-SIG XML topic to mention it.

XML-SIG and PyXML aren't as closely tied together as some people seem
to think (or atleast, they shouldn't be); any discussion of XML and
Python is welcome.

In fact, anybody who wants to get write access to the XML-SIG web
pages to expand their contents, just let me know.

> I think we should have as many tools as makes sense in PyXML.  My
> main question would be: what else do people need to have besides
> what is bundled in PyXML?  I assume libxml and the like, which is
> probably too much.

Provided there is proper setup.py magic to detect the prerequisites, I
think adding wrappers around existing libraries is a good thing to do.
As a result, different PyXML installation would offer different
parsers, but they do so, anyway, and there is (or should be) enough
framework to deal with installation variations.

Regards,
Martin

From uche.ogbuji@fourthought.com  Thu Feb 21 17:17:25 2002
From: uche.ogbuji@fourthought.com (Uche Ogbuji)
Date: 21 Feb 2002 10:17:25 -0700
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: 
References: <200202211502.g1LF2kD03794@localhost.localdomain>

Message-ID: <1014311845.1726.1982.camel@localhost.localdomain>

On Thu, 2002-02-21 at 10:15, Martin v. Loewis wrote:
> Uche Ogbuji  writes:
> 
> > Either way, I'd be happy to update the XML-SIG XML topic to mention it.
> 
> XML-SIG and PyXML aren't as closely tied together as some people seem
> to think (or atleast, they shouldn't be); any discussion of XML and
> Python is welcome.

Exactly.  Which is why I said I was happy to cover libxml in the XML
topic, even though it might not be a candidate for bundling in PyXML.

-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Boulder, CO 80301-2537, USA
XML strategy, XML tools (http://4Suite.org), knowledge management

From hannu@tm.ee  Thu Feb 21 17:31:28 2002
From: hannu@tm.ee (Hannu Krosing)
Date: 21 Feb 2002 19:31:28 +0200
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <20020221101738.X25311@redhat.com>
References: 
 <200202211502.g1LF2kD03794@localhost.localdomain>
 <20020221101738.X25311@redhat.com>
Message-ID: <1014312693.15078.4.camel@taru.tm.ee>

On Thu, 2002-02-21 at 17:17, Daniel Veillard wrote:
> On Thu, Feb 21, 2002 at 08:02:46AM -0700, Uche Ogbuji wrote:
> > I think we should have as many tools as makes sense in PyXML.  My main=20
> > question would be: what else do people need to have besides what is bun=
dled in=20
> > PyXML?  I assume libxml and the like, which is probably too much.
>=20
>   yup. I have been (mostly silently) following that list for the last mon=
th
> and it is clear that libxml2/libxslt is in a large part redundant. On the
> other hand I needed good Python bindings which would work with python 1.5
> even if ancient.

Should it work with python 2.2 ?

I'm able to import libxml2 fine but import libxslt gives

[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import libxml2mod
>>> import libxsltmod
Traceback (most recent call last):
  File "", line 1, in ?
ImportError: h=938=B5x@/libz.sow: shared object not open

Or should I just recompile without zlib ?

-----------------
Hannu

From veillard@redhat.com  Thu Feb 21 17:46:48 2002
From: veillard@redhat.com (Daniel Veillard)
Date: Thu, 21 Feb 2002 12:46:48 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <1014312693.15078.4.camel@taru.tm.ee>; from hannu@tm.ee on Thu, Feb 21, 2002 at 07:31:28PM +0200
References:  <200202211502.g1LF2kD03794@localhost.localdomain> <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee>
Message-ID: <20020221124648.B25311@redhat.com>

On Thu, Feb 21, 2002 at 07:31:28PM +0200, Hannu Krosing wrote:
> Should it work with python 2.2 ?

  In theory, yes. I think I tested it so far on Red Hat builds with
1.5, 2.1 and 2.2 for architectures i386, ia64 and alpha.

> I'm able to import libxml2 fine but import libxslt gives
>=20
> [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import libxml2mod
> >>> import libxsltmod
> Traceback (most recent call last):
>   File "", line 1, in ?
> ImportError: h=938=B5x@/libz.sow: shared object not open
>=20
> Or should I just recompile without zlib ?

  No, that's something I'm puzzled at, it had been reported
already and we could not find the problem yet:
  http://mail.gnome.org/archives/xml-bindings/2002-February/msg00014.html

 This seems related to something like:
   module A need shared lib l1
   module B need module A and shared lib l2
   shared lib l2 depends on a symbol from l1

and at that point the behaviour becomes unstable.=20
It could be that there is one explicit dependancy missing in the shared
object which makes the process unreliable. And there must be some memory
corruption going on (look at the string) but where !

Daniel

--=20
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

From mal@lemburg.com  Thu Feb 21 18:02:20 2002
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 21 Feb 2002 19:02:20 +0100
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
References:  <200202211502.g1LF2kD03794@localhost.localdomain> <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee> <20020221124648.B25311@redhat.com>
Message-ID: <3C75362C.B194EDFB@lemburg.com>

Daniel Veillard wrote:
>=20
> On Thu, Feb 21, 2002 at 07:31:28PM +0200, Hannu Krosing wrote:
> > Should it work with python 2.2 ?
>=20
>   In theory, yes. I think I tested it so far on Red Hat builds with
> 1.5, 2.1 and 2.2 for architectures i386, ia64 and alpha.
>=20
> > I'm able to import libxml2 fine but import libxslt gives
> >
> > [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import libxml2mod
> > >>> import libxsltmod
> > Traceback (most recent call last):
> >   File "", line 1, in ?
> > ImportError: h=938=B5x@/libz.sow: shared object not open
> >
> > Or should I just recompile without zlib ?
>=20
>   No, that's something I'm puzzled at, it had been reported
> already and we could not find the problem yet:
>   http://mail.gnome.org/archives/xml-bindings/2002-February/msg00014.ht=
ml
>=20
>  This seems related to something like:
>    module A need shared lib l1
>    module B need module A and shared lib l2
>    shared lib l2 depends on a symbol from l1

This is a bad thing for portability. You should never have
shared libs depend on each other -- dynamic linking will simply
screw up completely...=20
=20
> and at that point the behaviour becomes unstable.
> It could be that there is one explicit dependancy missing in the shared
> object which makes the process unreliable. And there must be some memor=
y
> corruption going on (look at the string) but where !

Probably in the dynamic linker of the OS. Also, on some
platforms each DLL uses it's own heap for memory=20
allocation.

Why not simply make l1 and l2 a single shared lib ?

--=20
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/

From mal@lemburg.com  Thu Feb 21 18:14:30 2002
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 21 Feb 2002 19:14:30 +0100
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
References:  <200202211502.g1LF2kD03794@localhost.localdomain> <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee> <20020221124648.B25311@redhat.com> <3C75362C.B194EDFB@lemburg.com>
Message-ID: <3C753906.9B8B84A9@lemburg.com>

"M.-A. Lemburg" wrote:
> 
> Daniel Veillard wrote:
> >
> >  This seems related to something like:
> >    module A need shared lib l1
> >    module B need module A and shared lib l2
> >    shared lib l2 depends on a symbol from l1

One other thing you could try is to have module A load
both l1 and l2, or if the dependencies are just l2 -> l1,
to assure that l1 is loaded prior to l2.

Still, I'd recommend choosing a different shared lib setup...

> This is a bad thing for portability. You should never have
> shared libs depend on each other -- dynamic linking will simply
> screw up completely...

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/

From fdrake@acm.org  Thu Feb 21 18:25:29 2002
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 21 Feb 2002 13:25:29 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <3C753906.9B8B84A9@lemburg.com>
References: 
 <200202211502.g1LF2kD03794@localhost.localdomain>
 <20020221101738.X25311@redhat.com>
 <1014312693.15078.4.camel@taru.tm.ee>
 <20020221124648.B25311@redhat.com>
 <3C75362C.B194EDFB@lemburg.com>
 <3C753906.9B8B84A9@lemburg.com>
Message-ID: <15477.15257.751979.892048@grendel.zope.com>

M.-A. Lemburg writes:
 > One other thing you could try is to have module A load
 > both l1 and l2, or if the dependencies are just l2 -> l1,
 > to assure that l1 is loaded prior to l2.

One possible issue is that, by default, Python does not load the
symbols from libraries loaded for dynamic modules.  Daniel, to test
this easily, try this before importing A or B:

------------------------------------------------
import dl
import sys

sys.setdlopenflags(dl.RTLD_NOW | dl.RTLD_GLOBAL)
------------------------------------------------

(From the docstring for sys.setdlopenflags().)

  -Fred

-- 
Fred L. Drake, Jr.  
PythonLabs at Zope Corporation

From hannu@tm.ee  Thu Feb 21 18:35:48 2002
From: hannu@tm.ee (Hannu Krosing)
Date: 21 Feb 2002 20:35:48 +0200
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <20020221124648.B25311@redhat.com>
References: 
 <200202211502.g1LF2kD03794@localhost.localdomain>
 <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee>
 <20020221124648.B25311@redhat.com>
Message-ID: <1014316554.1391.1.camel@taru.tm.ee>

On Thu, 2002-02-21 at 19:46, Daniel Veillard wrote:
> On Thu, Feb 21, 2002 at 07:31:28PM +0200, Hannu Krosing wrote:
> > Should it work with python 2.2 ?
>=20
>   In theory, yes. I think I tested it so far on Red Hat builds with
> 1.5, 2.1 and 2.2 for architectures i386, ia64 and alpha.
>=20
> > I'm able to import libxml2 fine but import libxslt gives
> >=20
> > [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import libxml2mod
> > >>> import libxsltmod
> > Traceback (most recent call last):
> >   File "", line 1, in ?
> > ImportError: h=938=B5x@/libz.sow: shared object not open
> >=20
> > Or should I just recompile without zlib ?
>=20
>   No, that's something I'm puzzled at, it had been reported
> already and we could not find the problem yet:
>   http://mail.gnome.org/archives/xml-bindings/2002-February/msg00014.html

The strange thing is that when I installed the RPM's it seems to work.

Could the RPMs be made for python2.1 and python2.2 as well ?

---------------
Hannu

From hannu@tm.ee  Thu Feb 21 18:40:04 2002
From: hannu@tm.ee (Hannu Krosing)
Date: 21 Feb 2002 20:40:04 +0200
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <15477.15257.751979.892048@grendel.zope.com>
References: 
 <200202211502.g1LF2kD03794@localhost.localdomain>
 <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee>
 <20020221124648.B25311@redhat.com> <3C75362C.B194EDFB@lemburg.com>
 <3C753906.9B8B84A9@lemburg.com>
 <15477.15257.751979.892048@grendel.zope.com>
Message-ID: <1014316809.1781.4.camel@taru.tm.ee>

On Thu, 2002-02-21 at 20:25, Fred L. Drake, Jr. wrote:
> 
> M.-A. Lemburg writes:
>  > One other thing you could try is to have module A load
>  > both l1 and l2, or if the dependencies are just l2 -> l1,
>  > to assure that l1 is loaded prior to l2.
> 
> One possible issue is that, by default, Python does not load the
> symbols from libraries loaded for dynamic modules.  Daniel, to test
> this easily, try this before importing A or B:
> 
> ------------------------------------------------
> import dl

>>> import dl
Traceback (most recent call last):
  File "", line 1, in ?
ImportError: No module named dl

This is on RH linux 7.1 with Python 2.2

-------------
Hannu

From fdrake@acm.org  Thu Feb 21 18:47:19 2002
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 21 Feb 2002 13:47:19 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <1014316809.1781.4.camel@taru.tm.ee>
References: 
 <200202211502.g1LF2kD03794@localhost.localdomain>
 <20020221101738.X25311@redhat.com>
 <1014312693.15078.4.camel@taru.tm.ee>
 <20020221124648.B25311@redhat.com>
 <3C75362C.B194EDFB@lemburg.com>
 <3C753906.9B8B84A9@lemburg.com>
 <15477.15257.751979.892048@grendel.zope.com>
 <1014316809.1781.4.camel@taru.tm.ee>
Message-ID: <15477.16567.392503.678563@grendel.zope.com>

Hannu Krosing writes:
 > >>> import dl
 > Traceback (most recent call last):
 >   File "", line 1, in ?
 > ImportError: No module named dl
 > 
 > This is on RH linux 7.1 with Python 2.2

That's annoying.  Did you install from the RPMs or build from source?
It looks like Python's default build will attempt to build it if it
can find the dlfcn.h header file, so either that wasn't found on the
machine it was built on, or that module was specifically not included
(which wouldn't be unreasonable, I suppose).

  -Fred

-- 
Fred L. Drake, Jr.  
PythonLabs at Zope Corporation

From hannu@tm.ee  Thu Feb 21 18:55:18 2002
From: hannu@tm.ee (Hannu Krosing)
Date: 21 Feb 2002 20:55:18 +0200
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <15477.16567.392503.678563@grendel.zope.com>
References: 
 <200202211502.g1LF2kD03794@localhost.localdomain>
 <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee>
 <20020221124648.B25311@redhat.com> <3C75362C.B194EDFB@lemburg.com>
 <3C753906.9B8B84A9@lemburg.com>
 <15477.15257.751979.892048@grendel.zope.com>
 <1014316809.1781.4.camel@taru.tm.ee>
 <15477.16567.392503.678563@grendel.zope.com>
Message-ID: <1014317723.1391.9.camel@taru.tm.ee>

On Thu, 2002-02-21 at 20:47, Fred L. Drake, Jr. wrote:
> 
> Hannu Krosing writes:
>  > >>> import dl
>  > Traceback (most recent call last):
>  >   File "", line 1, in ?
>  > ImportError: No module named dl
>  > 
>  > This is on RH linux 7.1 with Python 2.2
> 
> That's annoying.  Did you install from the RPMs or build from source?

This is 2.2c1 installed from RPMs

> It looks like Python's default build will attempt to build it if it
> can find the dlfcn.h header file, so either that wasn't found on the
> machine it was built on, or that module was specifically not included
> (which wouldn't be unreasonable, I suppose).

I looked them up in /usr/include/bits/dlfcn.h and wirth this it works

>>> sys.setdlopenflags(0x00002|0x00100)   
>>> import libxslt
>>>

So will this be the standard way to work with python 2.2 and libxslt ;)

--------------
Hannu

From veillard@redhat.com  Thu Feb 21 18:53:58 2002
From: veillard@redhat.com (Daniel Veillard)
Date: Thu, 21 Feb 2002 13:53:58 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <1014316554.1391.1.camel@taru.tm.ee>; from hannu@tm.ee on Thu, Feb 21, 2002 at 08:35:48PM +0200
References:  <200202211502.g1LF2kD03794@localhost.localdomain> <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee> <20020221124648.B25311@redhat.com> <1014316554.1391.1.camel@taru.tm.ee>
Message-ID: <20020221135358.C19758@redhat.com>

On Thu, Feb 21, 2002 at 08:35:48PM +0200, Hannu Krosing wrote:
> The strange thing is that when I installed the RPM's it seems to work.

  Hum, there is something fishy ...

> Could the RPMs be made for python2.1 and python2.2 as well ?

  The RPMs I ship should include 1.5 and 2.1 since I have those installed
on my build box (the RPMs specs detects the installed Python versions
and builds the modules for each of them):
backup:~ -> rpm -qilp /usr/src/redhat/RPMS/i386/libxslt-python-1.0.12-1.i386.rpm | grep .so
URL         : http://xmlsoft.org/XSLT/
/usr/lib/python1.5/site-packages/libxsltmod.so
/usr/lib/python2.1/site-packages/libxsltmod.so
backup:~ -> 

  I will rebuild and install the 2.2 RPM from RawHide so next release will
have all 3. I'm still puzzled by the whole issue.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

From veillard@redhat.com  Thu Feb 21 18:35:12 2002
From: veillard@redhat.com (Daniel Veillard)
Date: Thu, 21 Feb 2002 13:35:12 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <3C75362C.B194EDFB@lemburg.com>; from mal@lemburg.com on Thu, Feb 21, 2002 at 07:02:20PM +0100
References:  <200202211502.g1LF2kD03794@localhost.localdomain> <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee> <20020221124648.B25311@redhat.com> <3C75362C.B194EDFB@lemburg.com>
Message-ID: <20020221133512.A19758@redhat.com>

On Thu, Feb 21, 2002 at 07:02:20PM +0100, M.-A. Lemburg wrote:
> Daniel Veillard wrote:
> >  This seems related to something like:
> >    module A need shared lib l1
> >    module B need module A and shared lib l2
> >    shared lib l2 depends on a symbol from l1
> 
> This is a bad thing for portability. You should never have
> shared libs depend on each other -- dynamic linking will simply
> screw up completely... 

  Come'on zlib is shared and used for example by libpng. And if your
graphic library need it you would have to have a special version
of libpng statically compiled against zlib, nahhh you cannot impose
this, on any platform !

> Probably in the dynamic linker of the OS. Also, on some
> platforms each DLL uses it's own heap for memory 
> allocation.
> 
> Why not simply make l1 and l2 a single shared lib ?

  No I'm not gonna ship with library statically linked inside my
shared library. The linker should be fixed instead.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

From pyxml@xhaus.com  Thu Feb 21 14:06:32 2002
From: pyxml@xhaus.com (Alan Kennedy)
Date: Thu, 21 Feb 2002 14:06:32 EST5EDT
Subject: [XML-SIG] What belongs in pyXML?
Message-ID: <200202211917.OAA369444@spool8.valueweb.net>

Greetings All,

I just wanted to pose a question, to which everyone will 
probably have a different answer :-)

What belongs in pyXML?

I wasn't around when the python XML-SIG was formed (I've 
only been pythoneering for about 12 months now), but I've 
been watching XML since May 1997, and using it and XSLT 
since Summer 1998, and well remember the heady early days
when everything was new and exciting. I can imagine that 
the original remit for the python XML-SIG was to provide
good XML support in python.

How things have changed! Nowadays, XML really is 
everywhere, and there isn't a language in existence that 
doesn't have XML support. 

And Python has an embarrassment of riches in relation to 
XML. There is SAX and DOM support built into the standard 
distribution, including validating and non-validating 
parsers, pure python and native code parsers, SAX level 1 
and 2 support, etc, etc.

There are multiple independent libraries for DOM and XSLT, 
including 4Suite, Pirxx/Pyana and now libxml/libxslt, all 
of which are high-quality, standards-compliant and 
production-quality implementations.

And then there is the "exotic" support, such as RDF (4RDF, 
Redfoot), Schema, etc (pytrex, xsv).

And then there is the buzzing world of web services, where 
is at least half a dozen SOAP/XML-RPC implementations, and 
doubtless several WS?L implementations in the pipeline.

It appears (to me at least :-) that python really is *the* 
premier language for XML support.

So, against that background, I'd like to pose this question.

What is the *current* purpose of pyXML? 

I fairly sure I know what the purpose used to be. Has the 
purpose changed? Should it change?

Regards,

Alan.

---------------------------------------------
This message was sent using WebMail by CyberGate.
http://www.gate.net/webmail

From veillard@redhat.com  Thu Feb 21 18:47:23 2002
From: veillard@redhat.com (Daniel Veillard)
Date: Thu, 21 Feb 2002 13:47:23 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <15477.15257.751979.892048@grendel.zope.com>; from fdrake@acm.org on Thu, Feb 21, 2002 at 01:25:29PM -0500
References:  <200202211502.g1LF2kD03794@localhost.localdomain> <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee> <20020221124648.B25311@redhat.com> <3C75362C.B194EDFB@lemburg.com> <3C753906.9B8B84A9@lemburg.com> <15477.15257.751979.892048@grendel.zope.com>
Message-ID: <20020221134723.B19758@redhat.com>

On Thu, Feb 21, 2002 at 01:25:29PM -0500, Fred L. Drake, Jr. wrote:
> 
> M.-A. Lemburg writes:
>  > One other thing you could try is to have module A load
>  > both l1 and l2, or if the dependencies are just l2 -> l1,
>  > to assure that l1 is loaded prior to l2.
> 
> One possible issue is that, by default, Python does not load the
> symbols from libraries loaded for dynamic modules.  Daniel, to test
> this easily, try this before importing A or B:
> 
> ------------------------------------------------
> import dl
> import sys
> 
> sys.setdlopenflags(dl.RTLD_NOW | dl.RTLD_GLOBAL)
> ------------------------------------------------
> 
> (From the docstring for sys.setdlopenflags().)

  Hum, it sounds like the problem, dl doesn't seems present
on my system (1.5 though there is /usr/lib/python1.5/test/test_dl.py ???)

  Hannu, since I can't reproduce the linker problems myself, could
you try to see if changing libxsl.py to 
------------
try:
    import dl
    import sys
    sys.setdlopenflags(dl.RTLD_NOW | dl.RTLD_GLOBAL)
except:
    pass
import libxml2mod
import libxsltmod
import libxml2

#
# Everything below this point is automatically generated
#
------------
  rebuilding in the python dir (the libxslt.py should be updated
accordingly) does indeed fix the problem ?

  thanks in advance,

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

From fdrake@acm.org  Thu Feb 21 19:19:22 2002
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 21 Feb 2002 14:19:22 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <1014317723.1391.9.camel@taru.tm.ee>
References: 
 <200202211502.g1LF2kD03794@localhost.localdomain>
 <20020221101738.X25311@redhat.com>
 <1014312693.15078.4.camel@taru.tm.ee>
 <20020221124648.B25311@redhat.com>
 <3C75362C.B194EDFB@lemburg.com>
 <3C753906.9B8B84A9@lemburg.com>
 <15477.15257.751979.892048@grendel.zope.com>
 <1014316809.1781.4.camel@taru.tm.ee>
 <15477.16567.392503.678563@grendel.zope.com>
 <1014317723.1391.9.camel@taru.tm.ee>
Message-ID: <15477.18490.929083.210424@grendel.zope.com>

Hannu Krosing writes:
 > I looked them up in /usr/include/bits/dlfcn.h and wirth this it works
 > 
 > >>> sys.setdlopenflags(0x00002|0x00100)   
 > >>> import libxslt

That's not just annoying, that's down right ugly!  I don't know how
portable the constants are, either.  If this ends up being the only
way to deal with this problem, I'd hope the libxml2/libxslt modules
end up "wrapped" by modules written in Python that do something like
this:

------------------------------------------------
import sys

try:
    from dl import RTLD_GLOBAL, RTLD_NOW
except ImportError:
    # hopefully something better is available...
    RTLD_GLOBAL = 0x00100
    RTLD_NOW = 0x00002

flags = sys.getdlopenflags()
sys.setdlopenflags(RTLD_GLOBAL | RTLD_NOW)
try:
    import libxml2
    import libxslt
finally:
    sys.setdlopenflags(flags)
------------------------------------------------

 > So will this be the standard way to work with python 2.2 and libxslt ;)

Aaarrgghhh!

Actually, I think there is another option, but it really wonderful
either.  It might be better than this.  Both C extension modules can
be implemented by a single .so this way:

1. Implement two internal functions that do what the current
   init functions do; let's call these _init_1 and _init_2.

2. Write *two* init functions (initA and initB), each of which
   calls both _init_1 and _init_2.

3. Install the .so as A.so *and* B.so, so it doesn't matter which gets
   imported first.  When imported, both modules are initialized and
   inserted in sys.modules, so subsequent imports will pick up the
   cached module.

Somewhat painful, but it should avoid these library dependence
problems, at least in this case.

  -Fred

-- 
Fred L. Drake, Jr.  
PythonLabs at Zope Corporation

From fdrake@acm.org  Thu Feb 21 19:28:38 2002
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 21 Feb 2002 14:28:38 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <20020221133512.A19758@redhat.com>
References: 
 <200202211502.g1LF2kD03794@localhost.localdomain>
 <20020221101738.X25311@redhat.com>
 <1014312693.15078.4.camel@taru.tm.ee>
 <20020221124648.B25311@redhat.com>
 <3C75362C.B194EDFB@lemburg.com>
 <20020221133512.A19758@redhat.com>
Message-ID: <15477.19046.219108.249147@grendel.zope.com>

Daniel Veillard writes:
 >   Come'on zlib is shared and used for example by libpng. And if your
 > graphic library need it you would have to have a special version
 > of libpng statically compiled against zlib, nahhh you cannot impose
 > this, on any platform !

For modules which are loaded into the global symbol space, this isn't
a problem.  "Normal" linking of an application to it's libraries works
fine because of this, as does a dynamic object's use of libraries
loaded by the main application.  When different dynamic objects need
to share a library and RTLD_GLOBAL is not set, we have a very
different situation.  Hannu showed that sharing the symbol space makes
this problem go away.

I remember playing with this once, and I ended up linking the
dependent dynamic object to the other.  It worked, but it can be
fragile (due to the search for the first if the dependent object is
loaded first).  Basically, you'd need to add A.so to the link command
for B.so; I forget if there were any other magical parameters to
give.  This might be worth playing with.

 >   No I'm not gonna ship with library statically linked inside my
 > shared library. The linker should be fixed instead.

That's another option, even if you don't like it.  It helps avoid API
version dependence of the compiled module.

  -Fred

-- 
Fred L. Drake, Jr.  
PythonLabs at Zope Corporation

From fdrake@acm.org  Thu Feb 21 19:34:19 2002
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 21 Feb 2002 14:34:19 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <20020221134723.B19758@redhat.com>
References: 
 <200202211502.g1LF2kD03794@localhost.localdomain>
 <20020221101738.X25311@redhat.com>
 <1014312693.15078.4.camel@taru.tm.ee>
 <20020221124648.B25311@redhat.com>
 <3C75362C.B194EDFB@lemburg.com>
 <3C753906.9B8B84A9@lemburg.com>
 <15477.15257.751979.892048@grendel.zope.com>
 <20020221134723.B19758@redhat.com>
Message-ID: <15477.19387.663020.915762@grendel.zope.com>

Daniel Veillard writes:
 >   Hum, it sounds like the problem, dl doesn't seems present
 > on my system (1.5 though there is /usr/lib/python1.5/test/test_dl.py ???)

The dl module was never built by default using the old Modules/Setup
only build system.  RedHat should enable it specifically to allow
access to these constants, though!  The problem for Python is that
there is no winning combination of RTLD_* flags that works for
everyone.

  -Fred

-- 
Fred L. Drake, Jr.  
PythonLabs at Zope Corporation

From fdrake@acm.org  Thu Feb 21 20:05:24 2002
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 21 Feb 2002 15:05:24 -0500
Subject: [XML-SIG] minidom enhancements, 1st installment
Message-ID: <15477.21252.295147.650371@grendel.zope.com>

I've just checked in what I have so far into the minidom-enhancements
branch in CVS.  The perfomance checker script reports the following on
a RedHat 7.2 box with fairly current updates:

Python 2.0.1:
    using xml.dom.minidom.parseString(): 17.4418720007
    using xml.dom.expatbuilder.parseString(): 7.06486296654

Python 2.1.2:
    using xml.dom.minidom.parseString(): 16.3245279789
    using xml.dom.expatbuilder.parseString(): 6.71447992325

Python 2.2 + (maintenance branch from Python CVS):
    using xml.dom.minidom.parseString(): 13.8505721092
    using xml.dom.expatbuilder.parseString(): 6.86473989487

Python 2.3a0 (Python CVS trunk):
    using xml.dom.minidom.parseString(): 13.673410058
    using xml.dom.expatbuilder.parseString(): 6.74867010117

Times are in seconds, yada yada yada.  Read perf_expatbuilder.py to
see if you think it means anything.

  -Fred

-- 
Fred L. Drake, Jr.  
PythonLabs at Zope Corporation

From akuchlin@mems-exchange.org  Thu Feb 21 20:11:26 2002
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Thu, 21 Feb 2002 15:11:26 -0500
Subject: [XML-SIG] What belongs in pyXML?
In-Reply-To: <200202211917.OAA369444@spool8.valueweb.net>
References: <200202211917.OAA369444@spool8.valueweb.net>
Message-ID: <20020221201125.GA4550@crystal.mems-exchange.org>

On Thu, Feb 21, 2002 at 02:06:32PM +0000, Alan Kennedy wrote:
>What is the *current* purpose of pyXML? 

I don't think the PyXML package is really finished yet.  When I try to
use it for an application, I invariably find that there isn't quite
enough there -- I often have to write little snippets of code to
bridge Yet there's too much obsolete code still present in the
package, too many alternative readers with no clear indication of
which one to use, and no very friendly documentation (though I haven't
read the O'Reilly XML book yet).  In other words, it needs polishing.

I'd also like it if more people used the PyXML.cvs.sourceforge.net CVS
tree for their projects, even if they aren't destined for inclusion in
PyXML.  One irritating thing with SourceForge is that users mostly
create an entire new project for each separate thing, instead of
consolidating into a few larger projects.  For example, things like
Xerces/Xalan bindings would happily fit into the PyXML CVS, and more
of the Python XML-using community would then be aware of them.

--amk                                                  (www.amk.ca)
Oh, I know how many beans make five, Doctor. You don't have to be a
Time Lord to cope with A-level maths.
    -- The Brigadier, in "Mawdryn Undead"

From veillard@redhat.com  Thu Feb 21 20:41:57 2002
From: veillard@redhat.com (Daniel Veillard)
Date: Thu, 21 Feb 2002 15:41:57 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <15477.19046.219108.249147@grendel.zope.com>; from fdrake@acm.org on Thu, Feb 21, 2002 at 02:28:38PM -0500
References:  <200202211502.g1LF2kD03794@localhost.localdomain> <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee> <20020221124648.B25311@redhat.com> <3C75362C.B194EDFB@lemburg.com> <20020221133512.A19758@redhat.com> <15477.19046.219108.249147@grendel.zope.com>
Message-ID: <20020221154157.A31477@redhat.com>

On Thu, Feb 21, 2002 at 02:28:38PM -0500, Fred L. Drake, Jr. wrote:
> I remember playing with this once, and I ended up linking the
> dependent dynamic object to the other.  It worked, but it can be
> fragile (due to the search for the first if the dependent object is
> loaded first).  Basically, you'd need to add A.so to the link command
> for B.so; I forget if there were any other magical parameters to
> give.  This might be worth playing with.

  hum, actually both reports came from people who had recompiled 
the library themselves. I start suspecting some divergences in the
libtool processing. My version of libtool does the shared lib lookup

/bin/sh ../libtool --mode=link gcc  -Wall -g  -o libxsltmod.so -o libxsltmod.so libxslt.lo types.lo libxslt-py.lo ../libxslt/libxslt.la ../libexslt/libexslt.la  -shared -Wl,-soname,libxsltmod.so

launch 

gcc -Wall -g -o libxsltmod.so -o libxsltmod.so libxslt.o types.o libxslt-py.o -shared -Wl,-soname -Wl,libxsltmod.so  ../libxslt/.libs/libxslt.a -lm ../libexslt/.libs/libexslt.a -L/usr/lib /usr/lib/libxslt.so /usr/lib/libxml2.so -lm -lm -lm -lz -lm

But some other version might not do it, or may not activate it due
to prefix differences.
I will try to explictely add the references to libxml2, libz and libm,
but still they should use the same shared library instance, so the LD_GLOBAL
flag should be activated (when possible).

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

From fdrake@acm.org  Thu Feb 21 20:49:04 2002
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 21 Feb 2002 15:49:04 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <20020221154157.A31477@redhat.com>
References: 
 <200202211502.g1LF2kD03794@localhost.localdomain>
 <20020221101738.X25311@redhat.com>
 <1014312693.15078.4.camel@taru.tm.ee>
 <20020221124648.B25311@redhat.com>
 <3C75362C.B194EDFB@lemburg.com>
 <20020221133512.A19758@redhat.com>
 <15477.19046.219108.249147@grendel.zope.com>
 <20020221154157.A31477@redhat.com>
Message-ID: <15477.23872.905663.141001@grendel.zope.com>

Daniel Veillard writes:
 >   hum, actually both reports came from people who had recompiled 
 > the library themselves. I start suspecting some divergences in the
 > libtool processing. My version of libtool does the shared lib lookup

Just mentioning libtool puts the details beyond my understanding!

 > I will try to explictely add the references to libxml2, libz and libm,
 > but still they should use the same shared library instance, so the LD_GLOBAL
 > flag should be activated (when possible).

Then it looks like you'll have to use one of the setdlopenflags()
hacks.  ;-(  Just make sure you re-set the flags once you've done the
necessary imports.

This does reinforce the value of building the interpreter with many of
the standard modules built into the executable rather than dynamically
loaded.  Especially things like libz, since there are so many other
libraries that use them.

  -Fred

-- 
Fred L. Drake, Jr.  
PythonLabs at Zope Corporation

From martin@v.loewis.de  Thu Feb 21 23:45:31 2002
From: martin@v.loewis.de (Martin v. Loewis)
Date: 22 Feb 2002 00:45:31 +0100
Subject: [XML-SIG] regression testing framework
Message-ID: 

> If no one is currently working on this (or at least considering it),
> does anyone have any objections?

Go ahead and make any changes you like. A lot needs to be done in this
area, so any contribution is welcome.

Regards,
Martin

From dalsan@sparcs.kaist.ac.kr  Fri Feb 22 02:11:29 2002
From: dalsan@sparcs.kaist.ac.kr (Jinkuk Kim)
Date: Fri, 22 Feb 2002 11:11:29 +0900
Subject: [XML-SIG] [Q] Problem in installing 4Suite - 4XSLT
Message-ID: <20020222021129.GA20248@sparcs.kaist.ac.kr>

[Q] Problem in installing 4Suite - 4XSLT

 Hello, I'm Kim

 I want to use 4Suite to use XSLT in python, but i faced a problem installing it.

 first, I installed python2.2 and it worked well.
 (I downloaded src, and configure, make, make install ..)

 second, I installed PyXML-0.7 and i think it works well.
 because when i typed "from xml.dom.ext.reader import PyExpat"
 no error occured.
 (I downloaded src, and "python setup.py build", "python setup.py install" ..)

 third, I installed 4Suite-0.11.1 and i thought it was installed successfully,
 but when i typed "from xml.xslt.Processor import Processor"
 following error message was printed
 (I downloaded src, and "python setup.py install" ..)

Traceback (most recent call last):
 File "", line 1, in ?
 File "/usr/local/lib/python2.2/site-packages/_xmlplus/xslt/Processor.py", line 24, in ?
  from xml.xslt import StylesheetReader, ReleaseNode
 File "/usr/local/lib/python2.2/site-packages/_xmlplus/xslt/StylesheetReader.py", line 53, in ?
  from xml.xslt.Stylesheet import StylesheetElement
 File "/usr/local/lib/python2.2/site-packages/_xmlplus/xslt/Stylesheet.py", line 22, in ?
  from xml.xslt import XsltElement, XsltException, InternalException, Error
ImportError: cannot import name InternalException

 I checked the source file of Stylesheet.py,
 in that, xml.xslt.xpath.InternalException was imported,

 but when I checked site-packages/_xmlplus/xpath
 I couldn't find the definition of InternalException.

 I'm getting very difficulty solving this problem.
 please help solving my problem.

 * This installation was done on both Solaris8 and Debian Linuix,

From veillard@redhat.com  Fri Feb 22 09:21:29 2002
From: veillard@redhat.com (Daniel Veillard)
Date: Fri, 22 Feb 2002 04:21:29 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <15477.18490.929083.210424@grendel.zope.com>; from fdrake@acm.org on Thu, Feb 21, 2002 at 02:19:22PM -0500
References: <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee> <20020221124648.B25311@redhat.com> <3C75362C.B194EDFB@lemburg.com> <3C753906.9B8B84A9@lemburg.com> <15477.15257.751979.892048@grendel.zope.com> <1014316809.1781.4.camel@taru.tm.ee> <15477.16567.392503.678563@grendel.zope.com> <1014317723.1391.9.camel@taru.tm.ee> <15477.18490.929083.210424@grendel.zope.com>
Message-ID: <20020222042129.I31477@redhat.com>

On Thu, Feb 21, 2002 at 02:19:22PM -0500, Fred L. Drake, Jr. wrote:
> 
> Hannu Krosing writes:
>  > I looked them up in /usr/include/bits/dlfcn.h and wirth this it works
>  > 
>  > >>> sys.setdlopenflags(0x00002|0x00100)   
>  > >>> import libxslt
> 
> That's not just annoying, that's down right ugly!  I don't know how
> portable the constants are, either.  If this ends up being the only
> way to deal with this problem, I'd hope the libxml2/libxslt modules
> end up "wrapped" by modules written in Python that do something like
> this:

   thanks, I updated my wrappers to do something similar, but a bit
more careful checking first for the Os version before making any hardcoded
assumption. Also 1.5 here doesn't have sys.getdlopenflags ...

> Actually, I think there is another option, but it really wonderful
> either.  It might be better than this.  Both C extension modules can
> be implemented by a single .so this way:

  I would really prefer to avoid this for distribution purposes.

I have put updated RPMs of libxml2-python-2.4.16 and libxslt-python-1.0.12
with 2.2 modules at ftp://xmlsoft.org/test/

    Thanks for the help on this issue, I'm now looking at the setup.py docs,

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

From mal@lemburg.com  Fri Feb 22 09:24:16 2002
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 22 Feb 2002 10:24:16 +0100
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
References: 
 <200202211502.g1LF2kD03794@localhost.localdomain>
 <20020221101738.X25311@redhat.com>
 <1014312693.15078.4.camel@taru.tm.ee>
 <20020221124648.B25311@redhat.com>
 <3C75362C.B194EDFB@lemburg.com>
 <3C753906.9B8B84A9@lemburg.com>
 <15477.15257.751979.892048@grendel.zope.com>
 <1014316809.1781.4.camel@taru.tm.ee> <15477.16567.392503.678563@grendel.zope.com>
Message-ID: <3C760E40.916079E0@lemburg.com>

"Fred L. Drake, Jr." wrote:
> 
> Hannu Krosing writes:
>  > >>> import dl
>  > Traceback (most recent call last):
>  >   File "", line 1, in ?
>  > ImportError: No module named dl
>  >
>  > This is on RH linux 7.1 with Python 2.2
> 
> That's annoying.  Did you install from the RPMs or build from source?
> It looks like Python's default build will attempt to build it if it
> can find the dlfcn.h header file, so either that wasn't found on the
> machine it was built on, or that module was specifically not included
> (which wouldn't be unreasonable, I suppose).

Even if this works on some platforms, it won't on e.g. Windows.
It's better to find some other way to solve the problem, IMHO.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/

From veillard@redhat.com  Fri Feb 22 09:36:44 2002
From: veillard@redhat.com (Daniel Veillard)
Date: Fri, 22 Feb 2002 04:36:44 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <3C760E40.916079E0@lemburg.com>; from mal@lemburg.com on Fri, Feb 22, 2002 at 10:24:16AM +0100
References: <200202211502.g1LF2kD03794@localhost.localdomain> <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee> <20020221124648.B25311@redhat.com> <3C75362C.B194EDFB@lemburg.com> <3C753906.9B8B84A9@lemburg.com> <15477.15257.751979.892048@grendel.zope.com> <1014316809.1781.4.camel@taru.tm.ee> <15477.16567.392503.678563@grendel.zope.com> <3C760E40.916079E0@lemburg.com>
Message-ID: <20020222043644.J31477@redhat.com>

On Fri, Feb 22, 2002 at 10:24:16AM +0100, M.-A. Lemburg wrote:
> Even if this works on some platforms, it won't on e.g. Windows.

  Why ? Outside the Python framework people have no troubles using
binaries linked against shared libraries of libxml2 amd libxslt on
Windows.
    http://www.fh-frankfurt.de/~igor/projects/libxml/

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

From mal@lemburg.com  Fri Feb 22 10:08:37 2002
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 22 Feb 2002 11:08:37 +0100
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
References:  <200202211502.g1LF2kD03794@localhost.localdomain> <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee> <20020221124648.B25311@redhat.com> <3C75362C.B194EDFB@lemburg.com> <20020221133512.A19758@redhat.com>
Message-ID: <3C7618A5.91AAF29F@lemburg.com>

Daniel Veillard wrote:
> 
> On Thu, Feb 21, 2002 at 07:02:20PM +0100, M.-A. Lemburg wrote:
> > Daniel Veillard wrote:
> > >  This seems related to something like:
> > >    module A need shared lib l1
> > >    module B need module A and shared lib l2
> > >    shared lib l2 depends on a symbol from l1
> >
> > This is a bad thing for portability. You should never have
> > shared libs depend on each other -- dynamic linking will simply
> > screw up completely...
> 
>   Come'on zlib is shared and used for example by libpng. And if your
> graphic library need it you would have to have a special version
> of libpng statically compiled against zlib, nahhh you cannot impose
> this, on any platform !

If the dependencies are listed statically in the shared lib,
you don't have a problem -- the dynamic linker will then
load the lib on demand. However, Python loads module using
linker APIs, so the linking process is deferred and subject
to the linker options used for module import.

The problem is that Python does not use the RTLD_GLOBAL
option per default (I don't remember why, but do remember
there were some problems with making it the default). As
a result the symbols from the loaded DLLs are not made 
available to the process and neither to any other DLL
which might need them.

Now this is how it works on Linux... not sure about other
platforms. 

Note that Fred's trick with dynamically setting the
dlopen() flags only work on Python 2.2 and above.

> > Probably in the dynamic linker of the OS. Also, on some
> > platforms each DLL uses it's own heap for memory
> > allocation.
> >
> > Why not simply make l1 and l2 a single shared lib ?
> 
>   No I'm not gonna ship with library statically linked inside my
> shared library. The linker should be fixed instead.

You tell this Microsoft ;-)

Seriously, I think that Fred's second proposal (combining
the Python wrapper modules, rather than the libs) solves
this best. And it should work on all platforms and with all
Python versions.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/

From mal@lemburg.com  Fri Feb 22 10:17:57 2002
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 22 Feb 2002 11:17:57 +0100
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
References: <200202211502.g1LF2kD03794@localhost.localdomain> <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee> <20020221124648.B25311@redhat.com> <3C75362C.B194EDFB@lemburg.com> <3C753906.9B8B84A9@lemburg.com> <15477.15257.751979.892048@grendel.zope.com> <1014316809.1781.4.camel@taru.tm.ee> <15477.16567.392503.678563@grendel.zope.com> <3C760E40.916079E0@lemburg.com> <20020222043644.J31477@redhat.com>
Message-ID: <3C761AD5.6CF9886E@lemburg.com>

Daniel Veillard wrote:
> 
> On Fri, Feb 22, 2002 at 10:24:16AM +0100, M.-A. Lemburg wrote:
> > Even if this works on some platforms, it won't on e.g. Windows.
> 
>   Why ? Outside the Python framework people have no troubles using
> binaries linked against shared libraries of libxml2 amd libxslt on
> Windows.
>     http://www.fh-frankfurt.de/~igor/projects/libxml/

See my other reply and Fred's explanations. The problem is
due to the way Python imports modules. It does this
dynmically rather than at startup time since it is not known
in advance which modules will be needed by the process.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/

From veillard@redhat.com  Fri Feb 22 10:33:46 2002
From: veillard@redhat.com (Daniel Veillard)
Date: Fri, 22 Feb 2002 05:33:46 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <3C7618A5.91AAF29F@lemburg.com>; from mal@lemburg.com on Fri, Feb 22, 2002 at 11:08:37AM +0100
References:  <200202211502.g1LF2kD03794@localhost.localdomain> <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee> <20020221124648.B25311@redhat.com> <3C75362C.B194EDFB@lemburg.com> <20020221133512.A19758@redhat.com> <3C7618A5.91AAF29F@lemburg.com>
Message-ID: <20020222053346.L31477@redhat.com>

On Fri, Feb 22, 2002 at 11:08:37AM +0100, M.-A. Lemburg wrote:
> Daniel Veillard wrote:
> If the dependencies are listed statically in the shared lib,
> you don't have a problem -- the dynamic linker will then

  And it seems that with a recent libtool, this works.

> Now this is how it works on Linux... not sure about other
> platforms. 
> 
> Note that Fred's trick with dynamically setting the
> dlopen() flags only work on Python 2.2 and above.

  Seen that, this is only needed if the dependancy is not
provided within the library. With both combined this should
cover a reasonable fraction of the Unix user base.

> > > Why not simply make l1 and l2 a single shared lib ?
> > 
> >   No I'm not gonna ship with library statically linked inside my
> > shared library. The linker should be fixed instead.
> 
> You tell this Microsoft ;-)

  Me ? No, I didn't used it in the last 10 years.

> Seriously, I think that Fred's second proposal (combining
> the Python wrapper modules, rather than the libs) solves
> this best. And it should work on all platforms and with all
> Python versions.

  Except it seems to break my existing packaging model. Though
not cast in stone I really would not like to change the RPM mapping
too much. But I'm not sure I have looked at all the facet of Fred's
proposal and how to actually build the stuff that way, so I will
still try to get it working.
  Microsoft packaging is anyway a domain I can't touch, I really don't
have such a box and don't intend to in the foreseable future, though I
usually take portability patches gracefully !

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

From mal@lemburg.com  Fri Feb 22 10:43:26 2002
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 22 Feb 2002 11:43:26 +0100
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
References:  <200202211502.g1LF2kD03794@localhost.localdomain> <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee> <20020221124648.B25311@redhat.com> <3C75362C.B194EDFB@lemburg.com> <20020221133512.A19758@redhat.com> <3C7618A5.91AAF29F@lemburg.com> <20020222053346.L31477@redhat.com>
Message-ID: <3C7620CE.9100D8D6@lemburg.com>

Daniel Veillard wrote:
> 
> > Seriously, I think that Fred's second proposal (combining
> > the Python wrapper modules, rather than the libs) solves
> > this best. And it should work on all platforms and with all
> > Python versions.
> 
>   Except it seems to break my existing packaging model. Though
> not cast in stone I really would not like to change the RPM mapping
> too much. But I'm not sure I have looked at all the facet of Fred's
> proposal and how to actually build the stuff that way, so I will
> still try to get it working.

Ideal would be if you'd factor out the Python bindings completely.
Then you'd have three packages libxml2, libxslt and python-libxml.

The advantage of this approach is that you can then use setup.py
to build the Python binding and also combine the two bindings
into one (shouldn't be too hard, since you are generating
the wrappers anyway, I figure).

Your packaging would have to change in that *you* will have to
run the generator and then place the generated .c files into
the package. setup.py can then take it from there.

>   Microsoft packaging is anyway a domain I can't touch, I really don't
> have such a box and don't intend to in the foreseable future, though I
> usually take portability patches gracefully !

With distutils you get this for free !

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/

From veillard@redhat.com  Fri Feb 22 11:00:06 2002
From: veillard@redhat.com (Daniel Veillard)
Date: Fri, 22 Feb 2002 06:00:06 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <3C7620CE.9100D8D6@lemburg.com>; from mal@lemburg.com on Fri, Feb 22, 2002 at 11:43:26AM +0100
References:  <200202211502.g1LF2kD03794@localhost.localdomain> <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee> <20020221124648.B25311@redhat.com> <3C75362C.B194EDFB@lemburg.com> <20020221133512.A19758@redhat.com> <3C7618A5.91AAF29F@lemburg.com> <20020222053346.L31477@redhat.com> <3C7620CE.9100D8D6@lemburg.com>
Message-ID: <20020222060006.N31477@redhat.com>

On Fri, Feb 22, 2002 at 11:43:26AM +0100, M.-A. Lemburg wrote:
> Daniel Veillard wrote:
> > > Seriously, I think that Fred's second proposal (combining
> > > the Python wrapper modules, rather than the libs) solves
> > > this best. And it should work on all platforms and with all
> > > Python versions.
> > 
> >   Except it seems to break my existing packaging model. Though
> > not cast in stone I really would not like to change the RPM mapping
> > too much. But I'm not sure I have looked at all the facet of Fred's
> > proposal and how to actually build the stuff that way, so I will
> > still try to get it working.
> 
> Ideal would be if you'd factor out the Python bindings completely.
> Then you'd have three packages libxml2, libxslt and python-libxml.

  Well this does not match my setup and existing packaging:
     - the CVS trees, libxslt and libxml2 are in separate areas, each
       with a python dedicated subtree
     - the python binding testing are part of my regression tests
       I also use the python binding to make some regression tests
       of the libxml2 conformance, so decoupling those would IMHO
       be a step back.
     - the release schedules of libxml2 and libxslt are not tied,
       though I usually roll them simultaneously it's not a rule.
     - it should be possible to install the libxml2 python bindings
       without installing the libxslt package, I dislike the idea of
       putting a requirement in that direction.

> The advantage of this approach is that you can then use setup.py
> to build the Python binding and also combine the two bindings
> into one (shouldn't be too hard, since you are generating
> the wrappers anyway, I figure).

  95% of them are generated, yes, based on API description files
themselves generated in the libxml2/libxslt build.

> >   Microsoft packaging is anyway a domain I can't touch, I really don't
> > have such a box and don't intend to in the foreseable future, though I
> > usually take portability patches gracefully !
> 
> With distutils you get this for free !

  How does distutils tell me that the libxml2/libxslt libraries where
compiled with Cygwin versus MSC on the Windows platform ? The linking
conventions seems to require that information and going through the doc
of distutils I could not find anything about it.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

From mal@lemburg.com  Fri Feb 22 12:02:43 2002
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 22 Feb 2002 13:02:43 +0100
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
References:  <200202211502.g1LF2kD03794@localhost.localdomain> <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee> <20020221124648.B25311@redhat.com> <3C75362C.B194EDFB@lemburg.com> <20020221133512.A19758@redhat.com> <3C7618A5.91AAF29F@lemburg.com> <20020222053346.L31477@redhat.com> <3C7620CE.9100D8D6@lemburg.com> <20020222060006.N31477@redhat.com>
Message-ID: <3C763363.3380C73A@lemburg.com>

Daniel Veillard wrote:
> 
> On Fri, Feb 22, 2002 at 11:43:26AM +0100, M.-A. Lemburg wrote:
> > Daniel Veillard wrote:
> > > > Seriously, I think that Fred's second proposal (combining
> > > > the Python wrapper modules, rather than the libs) solves
> > > > this best. And it should work on all platforms and with all
> > > > Python versions.
> > >
> > >   Except it seems to break my existing packaging model. Though
> > > not cast in stone I really would not like to change the RPM mapping
> > > too much. But I'm not sure I have looked at all the facet of Fred's
> > > proposal and how to actually build the stuff that way, so I will
> > > still try to get it working.
> >
> > Ideal would be if you'd factor out the Python bindings completely.
> > Then you'd have three packages libxml2, libxslt and python-libxml.
> 
>   Well this does not match my setup and existing packaging:
>      - the CVS trees, libxslt and libxml2 are in separate areas, each
>        with a python dedicated subtree
>      - the python binding testing are part of my regression tests
>        I also use the python binding to make some regression tests
>        of the libxml2 conformance, so decoupling those would IMHO
>        be a step back.
>      - the release schedules of libxml2 and libxslt are not tied,
>        though I usually roll them simultaneously it's not a rule.
>      - it should be possible to install the libxml2 python bindings
>        without installing the libxslt package, I dislike the idea of
>        putting a requirement in that direction.

I don't think you have much of a choice :-/

Note that the conformance tests could be part of the Python
binding package (users will need Python anyway in order to
run them, so you already have an extra requirement). Also,
I don't think libxml2 would have much of a problem with
having to install libxslt too. And finally, you can have 
setup.py disable the xslt support at compilation time (e.g. 
if the lib is not found) by e.g. not defining a HAVE_LIBXSLT 
symbol or simply not including the necessary .c files.

> > The advantage of this approach is that you can then use setup.py
> > to build the Python binding and also combine the two bindings
> > into one (shouldn't be too hard, since you are generating
> > the wrappers anyway, I figure).
> 
>   95% of them are generated, yes, based on API description files
> themselves generated in the libxml2/libxslt build.
> 
> > >   Microsoft packaging is anyway a domain I can't touch, I really don't
> > > have such a box and don't intend to in the foreseable future, though I
> > > usually take portability patches gracefully !
> >
> > With distutils you get this for free !
> 
>   How does distutils tell me that the libxml2/libxslt libraries where
> compiled with Cygwin versus MSC on the Windows platform ? The linking
> conventions seems to require that information and going through the doc
> of distutils I could not find anything about it.

There is no way: both use .dll as extension. However, the overall
directory setup for cygwin is different from that of MS VC and
the cygwin support in distutils will automatically use the
Unix like paths while MS VC uses its own environment.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/

From Alexandre.Fayolle@logilab.fr  Fri Feb 22 15:20:57 2002
From: Alexandre.Fayolle@logilab.fr (Alexandre Fayolle)
Date: Fri, 22 Feb 2002 16:20:57 +0100 (CET)
Subject: [XML-SIG] quick stupid question
Message-ID: 

Is it legal to have a NULL character in an XML document?

I've seen different parsers behaving differently with such documents. 

Thanks

Alexandre Fayolle
-- 
LOGILAB, Paris (France).
http://www.logilab.com   http://www.logilab.fr  http://www.logilab.org
Narval, the first software agent available as free software (GPL).

From fdrake@acm.org  Fri Feb 22 15:53:08 2002
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Fri, 22 Feb 2002 10:53:08 -0500
Subject: [XML-SIG] quick stupid question
In-Reply-To: 
References: 
Message-ID: <15478.26980.620055.609398@grendel.zope.com>

Alexandre Fayolle writes:
 > Is it legal to have a NULL character in an XML document?
 > 
 > I've seen different parsers behaving differently with such documents. 

It is not a legal XML character.  See:

	http://www.w3.org/TR/REC-xml#charsets

  -Fred

-- 
Fred L. Drake, Jr.  
PythonLabs at Zope Corporation

From Alexandre.Fayolle@logilab.fr  Fri Feb 22 16:14:03 2002
From: Alexandre.Fayolle@logilab.fr (Alexandre Fayolle)
Date: Fri, 22 Feb 2002 17:14:03 +0100 (CET)
Subject: [XML-SIG] quick stupid question
In-Reply-To: <15478.26980.620055.609398@grendel.zope.com>
Message-ID: 

On Fri, 22 Feb 2002, Fred L. Drake, Jr. wrote:

> 
> Alexandre Fayolle writes:
>  > Is it legal to have a NULL character in an XML document?
>  > 
>  > I've seen different parsers behaving differently with such documents. 
> 
> It is not a legal XML character.  See:
> 
> 	http://www.w3.org/TR/REC-xml#charsets

Thanks. Expat complains, but it looks like xmlproc says nothing. 

Alexandre Fayolle
-- 
LOGILAB, Paris (France).
http://www.logilab.com   http://www.logilab.fr  http://www.logilab.org
Narval, the first software agent available as free software (GPL).

From fdrake@acm.org  Fri Feb 22 16:17:31 2002
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Fri, 22 Feb 2002 11:17:31 -0500
Subject: [XML-SIG] quick stupid question
In-Reply-To: 
References: <15478.26980.620055.609398@grendel.zope.com>

Message-ID: <15478.28443.78073.625083@grendel.zope.com>

Alexandre Fayolle writes:
 > Thanks. Expat complains, but it looks like xmlproc says nothing. 

Yeah, I knew Expat gets that right; it's one of my only test cases!
(The paucity of tests is on my list of things to fix for Expat.)

  -Fred

-- 
Fred L. Drake, Jr.  
PythonLabs at Zope Corporation

From veillard@redhat.com  Fri Feb 22 17:19:17 2002
From: veillard@redhat.com (Daniel Veillard)
Date: Fri, 22 Feb 2002 12:19:17 -0500
Subject: [XML-SIG] quick stupid question
In-Reply-To: <15478.28443.78073.625083@grendel.zope.com>; from fdrake@acm.org on Fri, Feb 22, 2002 at 11:17:31AM -0500
References: <15478.26980.620055.609398@grendel.zope.com>  <15478.28443.78073.625083@grendel.zope.com>
Message-ID: <20020222121917.Q31477@redhat.com>

On Fri, Feb 22, 2002 at 11:17:31AM -0500, Fred L. Drake, Jr. wrote:
> 
> Alexandre Fayolle writes:
>  > Thanks. Expat complains, but it looks like xmlproc says nothing. 
> 
> Yeah, I knew Expat gets that right; it's one of my only test cases!
> (The paucity of tests is on my list of things to fix for Expat.)

  there is the XML Test suite but most of them requires a parser
with validating capacity which expat can't do:
   http://www.oasis-open.org/committees/xml-conformance/index.shtml

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

From k_vertigo@yahoo.com  Fri Feb 22 23:00:45 2002
From: k_vertigo@yahoo.com (kapil thangavelu)
Date: Fri, 22 Feb 2002 15:00:45 -0800
Subject: [XML-SIG] WSDL library ?
In-Reply-To: <20020210181436.XKBH379.out019.verizon.net@there>
References: <20020210181436.XKBH379.out019.verizon.net@there>
Message-ID: <200202222147.g1MLl7377060@pimout3-int.prodigy.net>

another wsdl library (along with a soap implementation) is resting in zope cvs
http://cvs.zope.org/Packages/WebService/

not sure about its status.

cheers
kapil

On Sunday 10 February 2002 10:11 am, Eron Lloyd wrote:
> I've been playing with wsdllib, from a IBM developerWorks article by Uche.
> I've attached the actual module for you to look at. The article can be
> found here:
> http://www-105.ibm.com/developerworks/education.nsf/webservices-onlinecours
>e-bytitle/D092605075D1D67D86256A7E0042432D?OpenDocument
>
> Regards,
>
> Eron

From veillard@redhat.com  Fri Feb 22 23:16:36 2002
From: veillard@redhat.com (Daniel Veillard)
Date: Fri, 22 Feb 2002 18:16:36 -0500
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <15477.18490.929083.210424@grendel.zope.com>; from fdrake@acm.org on Thu, Feb 21, 2002 at 02:19:22PM -0500
References: <20020221101738.X25311@redhat.com> <1014312693.15078.4.camel@taru.tm.ee> <20020221124648.B25311@redhat.com> <3C75362C.B194EDFB@lemburg.com> <3C753906.9B8B84A9@lemburg.com> <15477.15257.751979.892048@grendel.zope.com> <1014316809.1781.4.camel@taru.tm.ee> <15477.16567.392503.678563@grendel.zope.com> <1014317723.1391.9.camel@taru.tm.ee> <15477.18490.929083.210424@grendel.zope.com>
Message-ID: <20020222181636.U31477@redhat.com>

On Thu, Feb 21, 2002 at 02:19:22PM -0500, Fred L. Drake, Jr. wrote:
> Actually, I think there is another option, but it really wonderful
> either.  It might be better than this.  Both C extension modules can
> be implemented by a single .so this way:
> 
> 1. Implement two internal functions that do what the current
>    init functions do; let's call these _init_1 and _init_2.
> 
> 2. Write *two* init functions (initA and initB), each of which
>    calls both _init_1 and _init_2.
> 
> 3. Install the .so as A.so *and* B.so, so it doesn't matter which gets
>    imported first.  When imported, both modules are initialized and
>    inserted in sys.modules, so subsequent imports will pick up the
>    cached module.
> 
> Somewhat painful, but it should avoid these library dependence
> problems, at least in this case.

   Okay, I have tried to do somthing along those lines. The setup.py
is "abnormaly" complex due to the fact:
    - that it generates the stubs for both libraries
    - it is tweaked to also be able to run from libxml2 distrib
      python subdir
    - that it may be used to build only the libxml2 package.

It requires xmllib or sgmlop to parse the APIs descriptions, but 
it seems to work even on my ancient 1.5 setup.

  I have uploaded the binding package at [*]
     ftp://xmlsoft.org/test/libxml2-python-2.4.16.tar.gz

It's probably not very portable, not that the C code is not portable but
I have no idea of the conventions needed to access libxml2 or libxslt
on Windows, nor how to "detect" the prefix for the include paths on Unix
from the python code (currently hardcoded to /usr/include/libxml2 and
/usr/include/libxslt). Portability patches are of course welcome.

I also didn't included the test in the package, the documentation on
distribuing python modules may be outdated (the PDF one) it says that
there is framework for tests but not implemented. So I left that out
for the moment.

Daniel

[*] that package is actually build from my development trees of libxml2
    and libxslt by a shell script merging the python parts and checking
    setup.py build sdist in that directory

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

From martin@v.loewis.de  Sat Feb 23 00:50:54 2002
From: martin@v.loewis.de (Martin v. Loewis)
Date: 23 Feb 2002 01:50:54 +0100
Subject: [XML-SIG] quick stupid question
In-Reply-To: 
References: 
Message-ID: 

Alexandre Fayolle  writes:

> Thanks. Expat complains, but it looks like xmlproc says nothing. 

Please file a bug report.

Martin

From martin@v.loewis.de  Sat Feb 23 00:54:57 2002
From: martin@v.loewis.de (Martin v. Loewis)
Date: 23 Feb 2002 01:54:57 +0100
Subject: [XML-SIG] Availability of libxml2 and libxslt Python bindings
In-Reply-To: <3C7618A5.91AAF29F@lemburg.com>
References: 
 <200202211502.g1LF2kD03794@localhost.localdomain>
 <20020221101738.X25311@redhat.com>
 <1014312693.15078.4.camel@taru.tm.ee>
 <20020221124648.B25311@redhat.com> <3C75362C.B194EDFB@lemburg.com>
 <20020221133512.A19758@redhat.com> <3C7618A5.91AAF29F@lemburg.com>
Message-ID: 

"M.-A. Lemburg"  writes:

> The problem is that Python does not use the RTLD_GLOBAL
> option per default (I don't remember why, but do remember
> there were some problems with making it the default).

The problem is that you would be exposing unrelated symbols, e.g. the
XML parsing library may conflict with your GUI library. One specific
incidence was that the Oracly library crashed because it got the
initsocket symbol from the Python module, not from its own shared
library.

> Now this is how it works on Linux... not sure about other
> platforms. 

On Windows, you always have local symbol resolution, since the
reference always refers to a (DLL name, symbol name) pair. On Mac OS
X, you currently have a flat namespace, which is a serious problem.

Regards,
Martin

From abottoni@quadrante.com  Mon Feb 25 09:50:37 2002
From: abottoni@quadrante.com (Alessandro Bottoni)
Date: Mon, 25 Feb 2002 01:50:37 -0800
Subject: [XML-SIG] Re: Maki: great!
References: <200202211453.g1LErv103729@localhost.localdomain>
Message-ID: <001801c1bde1$e0d325f0$de00a8c0@intranet.quadrante.com>

I apologize! I read the docs on your site a long time ago and I got
convinced it was a commercial product, probably because of the required
registration... Given this situation, I will re-take 4Suite into account for
my work.

----- Original Message -----
From: "Uche Ogbuji" 
To: "Alessandro Bottoni" 
Sent: Thursday, February 21, 2002 6:53 AM
Subject: Re: [XML-SIG] Re: Maki: great!

> 4SuiteServer
> 1) 4SuiteServer is a commercial application. When possible, I (we) avoid
to
> use commercial application, even if the cost is very, very low. The reason
> of this (arguable) behavior is that is becoming a nightmare to manage the
> huge amount of license documents/criteria and the continuos stream of
> licence expiration/payment events in our (already chaotic) production
> environment. For what regards me, I abandoned M$ for the same reasons a
long
> time ago.

Say what?

First of all, "4Suite server" has disappeared.  We've bundled the XML
repository right into 4Suite, as an easier way to manage the packaging and
development.

Secondly, 4Suite Server was always free and open-source.  We did request
people to register before the free download, as a fair exchange, but the
software was Apache license, which is about as free as it gets.

Certainly, now that the repository features have been merged into 4Suite,
there should be no more confusion on that matter.

--
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com
4735 East Walnut St, Boulder, CO 80301-2537, USA
XML strategy, XML tools (http://4Suite.org), knowledge management

From abottoni@quadrante.com  Mon Feb 25 10:32:14 2002
From: abottoni@quadrante.com (Alessandro Bottoni)
Date: Mon, 25 Feb 2002 02:32:14 -0800
Subject: [XML-SIG] Re: Maki: great!
References: 
Message-ID: <002101c1bde7$b147eae0$de00a8c0@intranet.quadrante.com>

----- Original Message -----
From: "Nicolas Chauvat" 
To: "Alessandro Bottoni" 
Cc: 
Sent: Thursday, February 21, 2002 4:23 AM
Subject: Re: [XML-SIG] Re: Maki: great!

-- omissis --
> Zope components (called Products in Zope talk) are a reality. They are far
> too difficult to build, IMHO, but I don't now of other Pyhon-based web
> framework that provide such reusability. I haven't used that many
> different ones, tho.
>
> As a conclusion, I think Zope needs much improvement indeed, but it's
> there and it works. Is it worth it to start completely from scratch ?

[Alessandro Bottoni]
I knew "Zope products" already... I agree with you about their "programmer
friendliness"...

There isn't any other python-based web framework like Zope available, as
long as I know.

Well, I think it is worth to create an alternative to Zope. Have a look at
ezPublish, PHPNuke or "Cocoon portal" and you will understand why... It is
not a matter of aesthethic or phylosophy: real-world web developers really
need fast development tools like those. They cannot spend weeks or months
studing complicated architectures like Zope just for having a simple,
working portal, like many others, as a final result. Do you remember? "Easy
things made easy and difficult things made manageables" That's what those
frameworks give us.

>
> > 4SuiteServer
> > 1) 4SuiteServer is a commercial application. When possible, I (we) avoid
to
> > use commercial application, even if the cost is very, very low. The
reason
> > of this (arguable) behavior is that is becoming a nightmare to manage
the
> > huge amount of license documents/criteria and the continuos stream of
> > licence expiration/payment events in our (already chaotic) production
> > environment. For what regards me, I abandoned M$ for the same reasons a
long
> > time ago.
>
> Beep [wrong answer]. 4SuiteServer is open source software ! Nothing there
> can be compared to M$ !!!
>

[Alessandro Bottoni]
I apologize for this: I was convinced it was a commercial product.

> > What I really need, is an open source, modular, easily configurable,
easily
> > extendable, pre-built portal. Something I can install in a couple of
hour,
> > prepare it for the customer in a couple of days and manage from script
and
> > external tools at my wish. Something that makes easy to create
task-specific
> > modules and that can accept new modules in a easy way. That is exactly
what
> > ezPublih gives me in the HTML field. That is what "Cocoon portal"
promises
> > in the XML arena. As long as I can see, nothing like that is available
in
> > the Python world, at the moment.
>
> "Build it and they will come." :-)
>

[Alessandro Bottoni]
I'm already studing the inner structure of ezPublish and Cocoon Portal. As
soon as I will have more freetime, I will try to develop a web framework of
that kind using the available python-based software (4Suite, Maki, WebWare
or whatever is suited for the task). Maybe, I will just be able to develop a
minimal skeleton: I do not know how much time I will be able to devote to
this project... In any case, I will try. At the moment, just one thing is
defined: it will be open source.

Again, it is not matter of  language religion: I just need something like
ezPublish and\or Cocoon portal for my day-to-day work and I do not really
consider the existing stuff completely satisfactory.

[The reasons why I do not consider PHP (PHPNuke and ezPublish) and Java
(Cocoon) satisfactory for this task should be evidents to python users: Java
is very slow and is arguably open source (no core java source is available
for free...). PHP is not a real "general purpose" language, so you are
forced to use at least two different languages for your day-to-day work (PHP
and Perl, e.g.). Python should be the "right" choice for this task.]

See you

Alessandro Bottoni

From alf@logilab.fr  Mon Feb 25 14:02:09 2002
From: alf@logilab.fr (alf@logilab.fr)
Date: Mon, 25 Feb 2002 15:02:09 +0100
Subject: [XML-SIG] Fwd: Problem with 4Dom xslt processor
Message-ID: <200202251402.PAA02288@sagittarius.logilab.fr>

I'm forwarding this message from c.l.p., in hope it will be answered 
here.

Alexandre Fayolle
----------------------------------------------------
From: sjoshi@ingr.com (Sunit Joshi)
Newsgroups: comp.lang.python
Subject: Problem with 4Dom xslt processor
Date: 19 Feb 2002 06:56:43 -0800

Hello all
I'm trying to use the 4DOM's xslt processor I keep getting this error
(below) when trying to append a stylesheet. Any pointers are greatly
appreciated.

thanks
Sunit

>>> from xml.xslt.Processor import Processor
>>> proc = Processor()
>>> proc

>>> proc.appendStylesheetUri('ships.xsl')
Traceback (most recent call last):
  File "", line 1, in ?
  File "C:\Python21\_xmlplus\xslt\Processor.py", line 95, in
appendStylesheetUri

    sty = self._styReader.fromUri(styleSheetUri, baseUri)
  File "C:\Python21\_xmlplus\xslt\StylesheetReader.py", line 297, in
fromUri
    ownerDoc, stripElements)
  File "C:\Python21\_xmlplus\xslt\minisupport.py", line 58, in fromUri
    return self.fromStream(stream, baseUri, ownerDoc, stripElements)
  File "C:\Python21\_xmlplus\xslt\StylesheetReader.py", line 304, in
fromStream
    self.initParser()
  File "C:\Python21\_xmlplus\xslt\StylesheetReader.py", line 344, in
initParser
    if self._force8Bit:
AttributeError: StylesheetReader instance has no attribute
'_force8Bit'

From Mike.Olson@fourthought.com  Mon Feb 25 17:16:01 2002
From: Mike.Olson@fourthought.com (Mike Olson)
Date: 25 Feb 2002 10:16:01 -0700
Subject: [XML-SIG] Fwd: Problem with 4Dom xslt processor
In-Reply-To: <200202251402.PAA02288@sagittarius.logilab.fr>
References: <200202251402.PAA02288@sagittarius.logilab.fr>
Message-ID: <1014657361.3150.2.camel@penny>

On Mon, 2002-02-25 at 07:02, Alexandre.Fayolle@logilab.fr wrote:
> 
> I'm forwarding this message from c.l.p., in hope it will be answered 
> here.

What verson of 4Suite and PyXML are you using?

Mike

> 
> Alexandre Fayolle
> ----------------------------------------------------
> From: sjoshi@ingr.com (Sunit Joshi)
> Newsgroups: comp.lang.python
> Subject: Problem with 4Dom xslt processor
> Date: 19 Feb 2002 06:56:43 -0800
> 
> Hello all
> I'm trying to use the 4DOM's xslt processor I keep getting this error
> (below) when trying to append a stylesheet. Any pointers are greatly
> appreciated.
> 
> thanks
> Sunit
> 
> >>> from xml.xslt.Processor import Processor
> >>> proc = Processor()
> >>> proc
> 
> >>> proc.appendStylesheetUri('ships.xsl')
> Traceback (most recent call last):
>   File "", line 1, in ?
>   File "C:\Python21\_xmlplus\xslt\Processor.py", line 95, in
> appendStylesheetUri
> 
>     sty = self._styReader.fromUri(styleSheetUri, baseUri)
>   File "C:\Python21\_xmlplus\xslt\StylesheetReader.py", line 297, in
> fromUri
>     ownerDoc, stripElements)
>   File "C:\Python21\_xmlplus\xslt\minisupport.py", line 58, in fromUri
>     return self.fromStream(stream, baseUri, ownerDoc, stripElements)
>   File "C:\Python21\_xmlplus\xslt\StylesheetReader.py", line 304, in
> fromStream
>     self.initParser()
>   File "C:\Python21\_xmlplus\xslt\StylesheetReader.py", line 344, in
> initParser
>     if self._force8Bit:
> AttributeError: StylesheetReader instance has no attribute
> '_force8Bit'
> 
> _______________________________________________
> XML-SIG maillist  -  XML-SIG@python.org
> http://mail.python.org/mailman/listinfo/xml-sig
-- 
Mike Olson                                Principal Consultant
mike.olson@fourthought.com                +1 303 583 9900 x 102
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St,                      http://4Suite.org
Boulder, CO 80301-2537, USA
XML strategy, XML tools, knowledge management

From norton@alum.mit.edu  Tue Feb 26 07:19:37 2002
From: norton@alum.mit.edu (Joseph Wayne Norton)
Date: Tue, 26 Feb 2002 16:19:37 +0900
Subject: [XML-SIG] problem with demo/xmlproc/dtd2schema.py
Message-ID: <874rk4pv5i.wl@namaste.tokyo.att.ne.jp>

Hello.

I just installed PyXML from the latest CVS checkout using python 2.1.2
on the linux platform.

Just for demo purposes, I tried running the dtd2schema.py demo utility
on the FIXML DTD (contained in the following bundle -
http://www.fixprotocol.org/cgi-bin/Spec.cgi?menu=4). However, I ran
into 2 issues listed below.

Any idea on where the problem might lie?

thanks,

- joe n.

1) I modifed the parsers/xmlplus/utils.py file by adding the missing
   locator parameter.

    class ErrorPrinter(xmlapp.ErrorHandler):
       """An error handler that prints out warning messages."""

    def __init__(self, locator, level = 0, out = sys.stderr):
        self.locator = locator
        self.level = level
        self.out = out

2) The reported errors seem correct but the warnings do not make sense
   to me.  I'm not able to see the corresponding issue in the dtd
   file.

norton@namaste:~/src/fix-doc$ /usr/local/Python-2.1.2/bin/python /home/norton/work/workbench/obj\
> /linux/PyXML-0.7/demo/xmlproc/dtd2schema.py fixml4.3v1.0.dtd.orig 

dtd2schema.py

Loading DTD...
WARNING: Attribute 'FIXTag' defined more than once at fixml4.3v1.0.dtd.orig:1292:1
WARNING: Attribute 'FIXTag' defined more than once at fixml4.3v1.0.dtd.orig:2178:1
WARNING: Attribute 'FIXTag' defined more than once at fixml4.3v1.0.dtd.orig:2621:26
WARNING: Attribute 'DataType' defined more than once at fixml4.3v1.0.dtd.orig:2622:26
WARNING: Attribute 'Value' defined more than once at fixml4.3v1.0.dtd.orig:2623:26
ERROR: Token 'NextDay' defined more than once at fixml4.3v1.0.dtd.orig:2707:16
WARNING: Attribute 'FIXTag' defined more than once at fixml4.3v1.0.dtd.orig:3954:2
WARNING: Attribute 'DataType' defined more than once at fixml4.3v1.0.dtd.orig:3955:2
WARNING: Attribute 'Value' defined more than once at fixml4.3v1.0.dtd.orig:3956:2
ERROR: Token 'M1' defined more than once at fixml4.3v1.0.dtd.orig:4203:95
ERROR: Token 'M2' defined more than once at fixml4.3v1.0.dtd.orig:4203:95
ERROR: Token 'MT' defined more than once at fixml4.3v1.0.dtd.orig:4203:95
Doing reverse-engineering...
Writing out schema

From noreply@sourceforge.net  Tue Feb 26 22:09:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Feb 2002 14:09:11 -0800
Subject: [XML-SIG] [ pyxml-Bugs-523159 ] RelaxNG Error
Message-ID: 

Bugs item #523159, was opened at 2002-02-26 14:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=106473&aid=523159&group_id=6473

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
Assigned to: Nobody/Anonymous (nobody)
Summary: RelaxNG Error

Initial Comment:
When I attempt to run demo.py or testall.py from the 
relax ng section of the sandbox, I get the following:

Traceback (most recent call last):
  File "D:\work\pyxml\sandbox\relaxng\demo.py", line 
68, in ?
    main()
  File "D:\work\pyxml\sandbox\relaxng\demo.py", line 
47, in main
    schema = fullparser.parse(stream)
  File "D:\work\pyxml\sandbox\relaxng\fullparser.py", 
line 592, in parse
    assert stream.get_next_event()[0] == 
pulldom.START_DOCUMENT
  File "D:\work\pyxml\sandbox\relaxng\util.py", line 
236, in get_next_event
    event, node = self.next()
  File "D:\work\pyxml\sandbox\relaxng\util.py", line 
178, in next
    event, node = self.stream.next()
AttributeError: DOMEventStream instance has no 
attribute 'next'

Looks like I don't have the right version of 
DOMEventStream, but I have what's in CVS.

Is there another version? Am I doing something wrong?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=106473&aid=523159&group_id=6473

From nef@ntu.edu.sg  Wed Feb 27 06:40:53 2002
From: nef@ntu.edu.sg (nef@ntu.edu.sg)
Date: Wed, 27 Feb 2002 14:40:53 +0800
Subject: [XML-SIG] SEAL'02-ICONIP'02-FSKD'02 Call For Papers
Message-ID: 

   [Sincere apologies if you receive multiple copies of this announce-
    ment or if you are not interested in it. We would greatly
    appreciate it if you could forward this CFP to your colleagues.]

----------------------------------------------------------------------
   4th Asia-Pacific Conference on Simulated Evolution And Learning
                          (SEAL'02)
    9th International Conference on Neural Information Processing
                         (ICONIP'02)
   International Conference on Fuzzy Systems and Knowledge Discovery
                          (FSKD'02)
----------------------------------------------------------------------
        November 18 - 22, 2002, Orchid Country Club, Singapore
                 http://www.ntu.edu.sg/home/nef

                         Organized by:
           School of Electrical and Electronic Engineering
             Nanyang Technological University, Singapore

                         Sponsored by:
               Asia-Pacific Neural Network Assembly
                 SEAL & FSKD Steering Committees

                      In Co-Operation with:
                   IEEE Neural Network Society
               International Neural Network Society
                  European Neural Network Society
                            SPIE

                         Supported by:
                        Lee Foundation
            Singapore Exhibition & Convention Bureau

               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
               CALL FOR PAPERS, SPONSORSHIPS, AND
                   SPECIAL SESSION PROPOSALS
               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SEAL'02, ICONIP'02, and FSKD'02 will be jointly held in Orchid Country
Club, Singapore from November 18 to 22, 2002. The conferences will
not only feature the most up-to-date research results in evolutionary
computation, neural information processing, fuzzy systems, and
knowledge discovery, but also promote cross-fertilization over these
exciting and yet closely-related areas. Registration to any one of the
conferences will entitle a participant to the technical sessions and
the proceedings of all three conferences, as well as the conference
banquet, buffet lunches, and tours to two of the major attractions in
Singapore, i.e., Night Safari and Sentosa Resort Island. Many well-
known researchers will present keynote speeches, panel discussions,
invited lectures, and tutorials.

About Singapore
---------------
Located at one of the most important crossroads of the world,
Singapore is truly a place where East and West come together. Here you
will find Chinese, Indian, and Malay communities living together,
their long established cultures forming a unique backdrop to a clean
and modern garden city. English is spoken everywhere and is the common
business language of all. Few places on earth promise such a delight
for the palate, with gourmet cuisine from over 30 countries. Exotic
resorts in neighboring countries are only a short bus/ferry ride away.

Orchid Country Club (OCC)
-------------------------
The venue for this year's conferences is at one of Singapore's
premier country clubs, a 25-minute bus ride from the city. Away from
the hustle and bustle of downtown Singapore, the tranquil setting of
the resort is ideal for serious technical discussions with an
accommodating space and ambience for relaxation. Not to miss out on
the splendor of downtown Singapore, the organizer has also secured
good quality and affordable accommodation in the heart of the city
with pre-arranged transport to/from the OCC. For golf enthusiasts,
OCC is equipped with the largest computerized driving range in South
East Asia and boasts of a 27-hole golf course with facilities for
night golfing, ideal for relaxation after each day of technical
discussions. Visit the OCC website at http://www.orchidclub.com

Night Safari and Sentosa Resort Island
--------------------------------------
It is said that a visit to Singapore is not complete without making
a trip to two of the Republic's famous attractions. The only one of
its kind in the world, the Night Safari provides a setting for
visitors to experience what it is like to observe animals in their
nocturnal habitat. The island of Sentosa offers some unique
attractions and a visit there will also provide a glimpse and
imagery of Singapore's past and present. Visits to these two
attractions will be included as recreation for the joint conference.
(Websites: http://www.zoo.com.sg/safari/, http://www.sentosa.com.sg)

Topics of Interest
------------------
The joint conferences welcomes paper submissions from researchers,
practitioners, and students worldwide in but not limited to the
following areas.

   SEAL'02:
   ~~~~~~~
   THEORY - Co-evolution, Coding methods, Collective behavior
   METHODOLOGY - Evolution strategies, Genetic algorithms, Genetic
       programming, Molecular and quantum computing, Evolvable
       hardware, Multi-objective optimization, Ant colony, Artificial
       ecology
   EVOLUTIONARY LEARNING - Artificial life, Bayesian evolutionary
       algorithms
   HYBRID SYSTEMS - Evolutionary neuro-fuzzy systems, Soft computing
   APPLICATIONS - Scheduling, Operations research, Design, etc

   ICONIP'02:
   ~~~~~~~~~
   NATURAL NEURAL SYSTEMS - Neuroscience, Neurobiology, Neuro-
       physiology, Brain imaging, Learning and memory
   ARTIFICIAL NEURAL MODELS - Learning algorithms, Neural modeling and
       architectures, Neurodynamics
   COGNITIVE SCIENCE - Perception, emotion, and cognition, Selective
       attention, Vision and auditory models
   HARDWARD IMPLEMENTATION - Artificial retina & cochlear chips
   HYBRID SYSTEMS - Neuro-fuzzy systems, Evolutionary neural nets, etc
   APPLICATIONS - Bioinformatics, Finance, Manufacturing, etc.

   FSKD'02:
   ~~~~~~~
   THEORY AND FOUNDATIONS - Fuzzy theory and models, Uncertainty
       management, Statistical & probabilistic data mining, Computing
       with words, Rough sets, Intelligent agents
   METHODS AND ALGORITHMS - Classification, Clustering, Information
       retrieval &  fusion, Data warehousing & OLAP, Fuzzy hardware,
       Visualization, Decision trees, Data preprocessing
   HYBRID SYSTEMS - Evolutionary neuro-fuzzy systems, Soft computing
   APPLICATIONS - Control, Optimization, Natural language processing,
       Forecasting, Human-computer interaction, etc.

Special Sessions
----------------
The conferences will feature special sessions on specialized topics
to encourage in-depth discussions. To propose a special session, email
the session title, name of the conference under which the special
session will be organized, contact information of the organizer(s),
and a short description on the theme and topics covered by the
session to Xin Yao, Special Sessions Chair (x.yao@cs.bham.ac.uk),
with a copy to Lipo Wang, General Chair (Cc: elpwang@ntu.edu.sg).

Sponsorship
-----------
The conferences will offer product vendors a sponsorship package
and/or an opportunity to interact with conference participants.
Product demonstration and exhibition can also be arranged. For more
information, please visit the conference website or contact
Tong Seng Quah, Sponsorship/Exhibition Chair (itsquah@ntu.edu.sg),
with a copy to Lipo Wang, General Chair (Cc: elpwang@ntu.edu.sg).

Keynote Speakers
----------------
Shun-ichi Amari, RIKEN Brain Science Institute, Japan
David Fogel, Natural Selection, Inc., USA
Mitsuo Kawato, ATR, Japan
Xin Yao, The University of Birmingham, UK
Lotfi A. Zadeh, University of California, USA

Registration Fee
----------------
The registration fee for regular participants before August 15, 2002
is S$680 (approximately US$370 as at February 6, 2002), which includes
the proceedings, lunches, banquet, and tours.

Submission of Papers
--------------------
Authors are invited to submit electronic files (postscript, pdf or
Word format) through the conference home page. Papers should be
double-column and use 10 pt Times Roman or similar fonts. The final
version of a paper should not exceed 5 pages in length. A selected
number of accepted papers will be expanded and revised for possible
inclusion in edited books and peer-reviewed journals, such as
"Soft Computing" and "Knowledge and Information Systems: An
International Journal" by Springer-Verlag.

Important Dates
---------------
	Paper/Summary Deadline     :   April 30, 2002
	Notification of Acceptance :   July 15, 2002
	Final Paper/ Registration  :   August 15, 2002

Honorary Conference Chairs
--------------------------
	Shun-ichi Amari, Japan
	Hans-Paul Schwefel, Germany
	Lotfi A. Zadeh, USA

International Advisory Board
----------------------------
	Sung-Yang Bang, Korea
	Meng Hwa Er, Singapore
	David B. Fogel, USA
	Toshio Fukuda, Japan
	A. Galushkin, Russia
	Tom Gedeon, Australia
	Zhenya He, China
	Mo Jamshidi, USA
	Nikola Kasabov, New Zealand
	Sun-Yuan Kung, USA
	Tong Heng Lee, Singapore
	Erkki Oja, Finland
	Nikhil R. Pal, India
	Enrique H. Ruspini,USA
	Harcharan Singh, Singapore
	Ah Chung Tsoi, Australia
	Shiro Usui, Toyohashi, Japan
	Lei Xu, China
	Benjamin W. Wah, USA
	Donald C. Wunsch II, USA
	Xindong Wu, USA
	Youshou Wu, China
	Yixin Zhong, China
	Jacek M. Zurada, USA

Advisor
-------
	Alex C. Kot, Singapore

General Chair
-------------
	Lipo Wang, Singapore

Program Co-Chairs
-----------------
	ICONIP'02:
		Kunihiko Fukushima, Japan
		Soo-Young Lee, Korea
		Jagath C. Rajapakse, Singapore
	SEAL'02:
		Takeshi Furuhashi, Japan
		Jong-Hwan Kim, Korea
		Kay Chen Tan, Singapore
	FSKD'02:
		Saman Halgamuge, Australia
	Special Sessions:
		Xin Yao, UK

Finance Chair
-------------
	Charoensak Charayaphan, Singapore

Local Arrangement Chair
-----------------------
	Meng Hiot Lim, Singapore

Proceedings Chair
-----------------
	Farook Sattar, Singapore

Publicity Chair
---------------
	Chunru Wan, Singapore

Sponsorship/Exhibition Chair
----------------------------
	Tong Seng Quah, Singapore

Tutorial Chair
--------------
	P. N. Suganthan, Singapore

For More Information
--------------------
Please visit the conference home page or contact:
	Lipo Wang, ICONIP'02-SEAL'02-FSKD'02 General Chair
	School of Electrical and Electronic Engineering
	Nanyang Technological University
	Block S2, 50 Nanyang Avenue, Singapore 639798
	Email: elpwang@ntu.edu.sg
	Phone: +65 6790 6372

Conference Secretariat
----------------------
	ICONIP'02-SEAL'02-FSKD'02 Secretariat
	Conference Management Center/CCE, NTU
	Administration Annex Building #04-06
	42 Nanyang Avenue, Singapore 639815
	Email: nef@ntu.edu.sg
	Fax:   +65 6793 0997

From thenault@isty-info.uvsq.fr  Wed Feb 27 15:55:14 2002
From: thenault@isty-info.uvsq.fr (Sylvain Thenault)
Date: Wed, 27 Feb 2002 16:55:14 +0100 (CET)
Subject: [XML-SIG] Fwd: Problem with 4Dom xslt processor
In-Reply-To: <200202251402.PAA02288@sagittarius.logilab.fr>
Message-ID: 

On Mon, 25 Feb 2002 Alexandre.Fayolle@logilab.fr wrote:

>
> I'm forwarding this message from c.l.p., in hope it will be answered
> here.
>
> Alexandre Fayolle
> ----------------------------------------------------
> From: sjoshi@ingr.com (Sunit Joshi)
> Newsgroups: comp.lang.python
> Subject: Problem with 4Dom xslt processor
> Date: 19 Feb 2002 06:56:43 -0800
>
> Hello all
> I'm trying to use the 4DOM's xslt processor I keep getting this error
> (below) when trying to append a stylesheet. Any pointers are greatly
> appreciated.
>
> thanks
> Sunit
>
> >>> from xml.xslt.Processor import Processor
> >>> proc = Processor()
> >>> proc
> 
> >>> proc.appendStylesheetUri('ships.xsl')
> Traceback (most recent call last):
>   File "", line 1, in ?
>   File "C:\Python21\_xmlplus\xslt\Processor.py", line 95, in
> appendStylesheetUri
>
>     sty = self._styReader.fromUri(styleSheetUri, baseUri)
>   File "C:\Python21\_xmlplus\xslt\StylesheetReader.py", line 297, in
> fromUri
>     ownerDoc, stripElements)
>   File "C:\Python21\_xmlplus\xslt\minisupport.py", line 58, in fromUri
>     return self.fromStream(stream, baseUri, ownerDoc, stripElements)
>   File "C:\Python21\_xmlplus\xslt\StylesheetReader.py", line 304, in
> fromStream
>     self.initParser()
>   File "C:\Python21\_xmlplus\xslt\StylesheetReader.py", line 344, in
> initParser
>     if self._force8Bit:
> AttributeError: StylesheetReader instance has no attribute
> '_force8Bit'

I have fixed this bug in the PyXMl CVS a few weeks ago

-- 
Sylvain Thenault

From noreply@sourceforge.net  Wed Feb 27 15:47:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Feb 2002 07:47:02 -0800
Subject: [XML-SIG] [ pyxml-Bugs-523439 ] Installer does not find Zope Python
Message-ID: 

Bugs item #523439, was opened at 2002-02-27 07:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=106473&aid=523439&group_id=6473

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installer does not find Zope Python

Initial Comment:
I downloaded and ran PyXML-0.7.win32-py2.1.exe, but it 
does not show any installation of Python.  I have 
python 2.1 installed as part of Zope 2.4.2.

Why doesn't it find it?  Is there a way I can force it 
to look in a certian directory?

THanks
Mark

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=106473&aid=523439&group_id=6473

From webmaster@label.co.kr  Wed Feb 27 22:44:49 2002
From: webmaster@label.co.kr (=?ks_c_5601-1987?B?v8DHx726x8G288Da?=)
Date: Thu, 28 Feb 2002 07:44:49 +0900
Subject: [XML-SIG] =?ks_c_5601-1987?B?tvO6p1MvVyC5q7fhKLv1v+zG7bn4yKMgwNq1v8DUt8IpW8irurhd?=
Message-ID: <3c7d614f3c7f1a04@relay5.kornet.net> (added by relay5.kornet.net)

This is a multi-part message in MIME format.

------=_NextPart_000_0077_01C0F44A.93A49C00
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

tvO6p8fBt86x17elILmrt+Eou/W/7MbtufjIoyDA2rW/wNS3wikgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIA0KLSC/+MfPtMIgsO2wtL+hvLwgRE0gwNq34bnfvNsNCiAt
IL/4x8+0wiCw7bC0v6Gw1CBUZWxlbWFya2V0aW5nDQogLSC287qnwfYgw+K3wiDA/LmuIFMv
VyCzu8DlDQogLSCwy7v2tcggsOGw+rimILjeuPDA5b+hIMD6wOUsIMiwv+sNCiANCqjnIFu7
88ijL773wb7G7V0gOiDA/LG5IDQwMLi4ILvzyKMvvvfBviC1pcDMxbggvPa3zw0KIKjoIFvA
zrjtxu1dIDogwPyxuSAxLDIwMLi4IMDOuO0gtaXAzMW4ILz2t88gDQogsbjA1CCw7bC0v6Gw
1LTCILbzuqe/68H2IDGxxyg1MLjFL0E0KcC7ILvnwLrHsMC4t84gteW4s7TPtNkuDQogICAg
DQogICAgICAgICAgICAgICAgICAgIMiruri/6yC+yLO7ua7AuyC89sO1LCC89ri4ILDtsLS6
0LXpsrIgurizvbTZsO0gu/2wosfYICC6uLy8v+QuIA0KIMDOt8Kw+iC4ucC6IL3DsKPAuyC1
6b+pILjnxKUgvt+x2cfYILChuOm8rSDA2773x9IgvcOwo7+hIMG7ILT1IMi/wLINCiDA+8DO
IMDPwLsgx8+9w7TCsNQgvu62s7Huv+Q/IERNwNu+98C6IMD6yPHH0cXXILjDseK9yr3Dv+Qu
DQogDQogwPq3xcfPsO0gvcW808fPsNQgsO2wtL+pt6+60MDHIMGkvLrAuyC0477GvK0gv+zG
7bmwILnfvNvAuyDDpcDTwfYNCiCw2r3AtM+02S4gICAgDQogDQogDQogICAgICAgICAgICAg
ICAgICAgv+zG7bmwud+82yhETSnAuyDAp8fRILTru/MgsO2wtMDHIMHWvNK3zyC1pcDMxbgg
ILG4w+AsIMDOvOK5sLfOILXHvu4NCiDA1rTCIMDat+HAxyDA1LfCILTrx+AsILHiwbggwda8
0rfPILWlwMzFuMDHILv1v+zG7bn4yKMguq/IryDA2773te7AuyANCiDD1r3FILHivPq3ziC5
q8Dlx9EgwPy5rr/kv/i16cDMIL+pt6+60MC7ILW1v8215bixILDNwNS0z7TZLg0KIA0KIKK6
IFdlYi10by1EQiA6IMDMwaggILHXuLLAxyC2scC7IMH3waIguNTAuyC89iDA1r3AtM+02S4N
CiAgwM7FzbPdIL3HvcOwoyDB1rzStaXAzMW4uKYgv6K8v8bEwM+3ziC4uLXpvu4gteW4s7TP
tNkuDQogICi/uSA6IGh0dHA6Ly90ZWwuaGFubWlyLmNvbSAox9G5zLijIMD8yK25+MijILDL
u/YpKQ0KIA0KIKK6ILWlwMzFuCDA1LfCDQogorogwda80iC287qnIMPit8IgIA0KIKK6ILv1
v+zG7bn4yKMguq/IryAgICAgICAgICAgICAgICAgICANCiDAzLjewM8gwda80rTCIMDOxc2z
3SC8rcfOwLsgxevH2CC89sH9x8+/tMC4uOcsIMDMuN7AzyDB1rzSIL/cv6G0wiC+7rawx9Eg
waS6uLW1ILChwfaw7SDA1sH2IL7KvcC0z7TZLg0KILT1wMy78yC43sDPwLsgv/jEoSC+ysC4
vcO46SC89r3FsMW6zrimIMWsuK8gx9jB1ry8v+QuIMHBwLogx8+35yC6uLO7vLy/5C4NCiAN
CiBbvPa9xbDFus5dIA0KIA0KICAgICAgICAgICAgICAgICAgDQo=

------=_NextPart_000_0077_01C0F44A.93A49C00
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT6287qnx8G3zrHXt6Uguau34Si79b/sxu25+MijIMDa
tb/A1LfCKTwvdGl0bGU+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRl
bnQ9InRleHQvaHRtbDsgY2hhcnNldD1ldWMta3IiPg0KPHN0eWxlIHR5cGU9InRleHQvY3Nz
Ij4NCjwhLS0NCi5saXN0MDEgeyAgZm9udC1mYW1pbHk6ICKxvLiyIiwgIrG8uLLDvCI7IGZv
bnQtc2l6ZTogOXB0OyBjb2xvcjogIzRDNEM0QzsgIGxpbmUtaGVpZ2h0OiAxMnB0fQ0KLmxp
c3QwMiB7ICBmb250LWZhbWlseTogIrG8uLIiLCAisby4ssO8IjsgZm9udC1zaXplOiAxMHB0
OyBjb2xvcjogIzRDNEM0QzsgIGxpbmUtaGVpZ2h0OiAxNnB0fQ0KYTpsaW5re3RleHQtZGVj
b3JhdGlvbjpub25lO2NvbG9yOiM0QzRDNEM7Rk9OVDp9DQphOnZpc2l0ZWR7dGV4dC1kZWNv
cmF0aW9uOm5vbmU7Y29sb3I6IzRDNEM0QztGT05UOn0NCmE6YWN0aXZle3RleHQtZGVjb3Jh
dGlvbjpub25lO2NvbG9yOiNGRjMzOTk7Rk9OVDp9DQphOmhvdmVye3RleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7Y29sb3I6I0ZGMzM5OTtGT05UOn0NCi0tPg0KPC9zdHlsZT4NCjwvaGVh
ZD4NCg0KPGJvZHkgYmdjb2xvcj0iI2QwZDBkMCIgdGV4dD0iIzAwMDAwMCIgbGVmdG1hcmdp
bj0iMCIgdG9wbWFyZ2luPSIwIiBtYXJnaW53aWR0aD0iMCIgbWFyZ2luaGVpZ2h0PSIwIj4N
CjxkaXYgYWxpZ249ImNlbnRlciI+IA0KICA8dGFibGUgd2lkdGg9IjYwMCIgYm9yZGVyPSIw
IiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KICAgIDx0ciB2YWxpZ249InRv
cCI+IA0KICAgICAgPHRkIGJnY29sb3I9IiM5OTk5OTkiIGFsaWduPSJsZWZ0IiB3aWR0aD0i
MSI+PGltZyBzcmM9Imh0dHA6Ly93d3cubGFiZWwuY28ua3Ivb2ZmaWNlX21haWwvb3BpbWcv
aW1nMWsuZ2lmIiB3aWR0aD0iMSIgaGVpZ2h0PSIxIj48L3RkPg0KICAgICAgPHRkIHdpZHRo
PSI1OTgiIGJnY29sb3I9IiNGRkZGRkYiPiANCiAgICAgICAgPHRhYmxlIHdpZHRoPSI1OTgi
IGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCiAgICAgICAg
ICA8dHIgdmFsaWduPSJ0b3AiPiANCiAgICAgICAgICAgIDx0ZD48YSBocmVmPSJodHRwOi8v
d3d3LmxhYmVsLmNvLmtyIiB0YXJnZXQ9Il9ibGFuayI+PGltZyBzcmM9Imh0dHA6Ly93d3cu
bGFiZWwuY28ua3Ivb2ZmaWNlX21haWwvb3BpbWcvbG9nby5naWYiIHdpZHRoPSIxNzAiIGhl
aWdodD0iNzAiIGJvcmRlcj0iMCI+PC9hPjwvdGQ+DQogICAgICAgICAgICA8dGQgYmdjb2xv
cj0iI0ZGRkZGRiI+PGltZyBzcmM9Imh0dHA6Ly93d3cubGFiZWwuY28ua3Ivb2ZmaWNlX21h
aWwvb3BpbWcvbG9nb18wMS5naWYiIHdpZHRoPSIyMDAiIGhlaWdodD0iNzAiPjwvdGQ+DQog
ICAgICAgICAgICA8dGQ+PGltZyBzcmM9Imh0dHA6Ly93d3cubGFiZWwuY28ua3Ivb2ZmaWNl
X21haWwvb3BpbWcvbG9nb18wMi5naWYiIHdpZHRoPSIyMjgiIGhlaWdodD0iNzAiIHVzZW1h
cD0iI01hcDIiIGJvcmRlcj0iMCI+PG1hcCBuYW1lPSJNYXAyIj48YXJlYSBzaGFwZT0icmVj
dCIgY29vcmRzPSI0MiwzMCwyMjUsNjgiIGhyZWY9Imh0dHA6Ly93d3cubGFiZWwuY28ua3Ii
IHRhcmdldD0iX2JsYW5rIj48L21hcD48L3RkPg0KICAgICAgICAgIDwvdHI+DQogICAgICAg
IDwvdGFibGU+DQogICAgICAgIDx0YWJsZSB3aWR0aD0iNTk4IiBib3JkZXI9IjAiIGNlbGxz
cGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQogICAgICAgICAgPHRyPg0KICAgICAgICAg
ICAgPHRkIHZhbGlnbj0idG9wIj48aW1nIHNyYz0iaHR0cDovL3d3dy5sYWJlbC5jby5rci9v
ZmZpY2VfbWFpbC9vcGltZy9tYWluX3YuanBnIiB3aWR0aD0iNTk4IiBoZWlnaHQ9IjE3MiIg
dXNlbWFwPSIjTWFwIiBib3JkZXI9IjAiPjxtYXAgbmFtZT0iTWFwIj48YXJlYSBzaGFwZT0i
cmVjdCIgY29vcmRzPSIzMzUsMzYsNTkyLDEzMSIgaHJlZj0iaHR0cDovL3d3dy5sYWJlbC5j
by5rci9odG1sL3Bkcy9uZXdwb3N0Lmh0bSIgdGFyZ2V0PSJfYmxhbmsiPjxhcmVhIHNoYXBl
PSJyZWN0IiBjb29yZHM9IjQ2MSwxMzksNTE3LDE1NiIgaHJlZj0iaHR0cDovL3d3dy5sYWJl
bC5jby5rci9odG1sL3Bkcy9wb3N0YWxjb2RlLmh0bSIgdGFyZ2V0PSJfYmxhbmsiPjwvbWFw
PjwvdGQ+DQogICAgICAgICAgPC90cj4NCiAgICAgICAgPC90YWJsZT4NCiAgICAgICAgPHRh
YmxlIHdpZHRoPSI1OTgiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5n
PSIwIj4NCiAgICAgICAgICA8dHI+DQogICAgICAgICAgICA8dGQgdmFsaWduPSJ0b3AiPjxp
bWcgc3JjPSJodHRwOi8vd3d3LmxhYmVsLmNvLmtyL29mZmljZV9tYWlsL29waW1nL3R0X2Jh
ci5naWYiIHdpZHRoPSI1OTgiIGhlaWdodD0iMjAiPjwvdGQ+DQogICAgICAgICAgPC90cj4N
CiAgICAgICAgPC90YWJsZT4NCiAgICAgICAgPHRhYmxlIHdpZHRoPSI1OTgiIGJvcmRlcj0i
MCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCiAgICAgICAgICA8dHIgdmFs
aWduPSJ0b3AiPiANCiAgICAgICAgICAgIDx0ZCB3aWR0aD0iMTcwIj48aW1nIHNyYz0iaHR0
cDovL3d3dy5sYWJlbC5jby5rci9vZmZpY2VfbWFpbC9vcGltZy9waWMxMTAxLmdpZiIgd2lk
dGg9IjE3MCIgaGVpZ2h0PSIyNSI+PC90ZD4NCiAgICAgICAgICAgIDx0ZD48aW1nIHNyYz0i
aHR0cDovL3d3dy5sYWJlbC5jby5rci9vZmZpY2VfbWFpbC9vcGltZy9waWMxMTAyLmdpZiIg
d2lkdGg9IjQyOCIgaGVpZ2h0PSIyNSI+PC90ZD4NCiAgICAgICAgICA8L3RyPg0KICAgICAg
ICAgIDx0ciB2YWxpZ249InRvcCI+IA0KICAgICAgICAgICAgPHRkIHdpZHRoPSIxNzAiPjxp
bWcgc3JjPSJodHRwOi8vd3d3LmxhYmVsLmNvLmtyL29mZmljZV9tYWlsL29waW1nL3BpYzEx
MDMuZ2lmIiB3aWR0aD0iMTcwIiBoZWlnaHQ9IjE2NSI+PC90ZD4NCiAgICAgICAgICAgIDx0
ZCBiZ2NvbG9yPSIjRkZGRkZGIj4gDQogICAgICAgICAgICAgIDx0YWJsZSB3aWR0aD0iNDI4
IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQogICAgICAg
ICAgICAgICAgPHRyIHZhbGlnbj0idG9wIj4gDQogICAgICAgICAgICAgICAgICA8dGQgd2lk
dGg9IjIwIiBjbGFzcz0ibGlzdDAxIj48aW1nIHNyYz0iaHR0cDovL3d3dy5sYWJlbC5jby5r
ci9vZmZpY2VfbWFpbC9vcGltZy9pbWcxay5naWYiIHdpZHRoPSIyMCIgaGVpZ2h0PSIyMCI+
PC90ZD4NCiAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iNDA4IiBjbGFzcz0ibGlzdDAx
Ij4gDQogICAgICAgICAgICAgICAgICAgIDxwPi0gv/jHz7TCILDtsLS/oby8IERNIMDat+G5
37zbPGJyPg0KICAgICAgICAgICAgICAgICAgICAgIC0gv/jHz7TCILDtsLS/obDUIFRlbGVt
YXJrZXRpbmc8YnI+DQogICAgICAgICAgICAgICAgICAgICAgLSC287qnwfYgw+K3wiDA/Lmu
IFMvVyCzu8DlPGJyPg0KICAgICAgICAgICAgICAgICAgICAgIC0gsMu79rXIILDhsPq4piC4
3rjwwOW/oSDA+sDlLCDIsL/rPC9wPg0KICAgICAgICAgICAgICAgICAgICA8cD4gPGI+qOcg
W7vzyKMvvvfBvsbtXSA6IDwvYj4gwPyxuSA0MDC4uCC788ijL773wb4gtaXAzMW4ILz2t888
YnI+DQogICAgICAgICAgICAgICAgICAgICAgPGI+qOggW8DOuO3G7V0gOjwvYj4gwPyxuSAx
LDIwMLi4IMDOuO0gtaXAzMW4ILz2t88gPGJyPg0KICAgICAgICAgICAgICAgICAgICAgIDxm
b250IGNvbG9yPSIjRkY2NjAwIj6xuMDUILDtsLS/obDUtMIgtvO6p7/rwfYgMbHHKDUwuMUv
QTQpwLsgu+fAusewwLi3ziC15biztM+02S48L2ZvbnQ+PC9wPg0KICAgICAgICAgICAgICAg
ICAgICA8L3RkPg0KICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgIDwvdGFi
bGU+DQogICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgPHRhYmxlIHdpZHRoPSI0
MjgiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCiAgICAg
ICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAgICAgICA8dGQgdmFsaWduPSJ0b3AiIGFs
aWduPSJyaWdodCI+PGEgaHJlZj0iaHR0cDovL3d3dy5sYWJlbC5jby5rci9odG1sL3Byb2R1
Y3QvcGhvbmVjZC5odG0iIHRhcmdldD0iX2JsYW5rIj48aW1nIHNyYz0iaHR0cDovL3d3dy5s
YWJlbC5jby5rci9vZmZpY2VfbWFpbC9vcGltZy9tb3JlLmdpZiIgd2lkdGg9IjY5IiBoZWln
aHQ9IjExIiBib3JkZXI9IjAiPjwvYT48L3RkPg0KICAgICAgICAgICAgICAgIDwvdHI+DQog
ICAgICAgICAgICAgIDwvdGFibGU+DQogICAgICAgICAgICA8L3RkPg0KICAgICAgICAgIDwv
dHI+DQogICAgICAgIDwvdGFibGU+DQogICAgICAgIDx0YWJsZSB3aWR0aD0iNTk4IiBib3Jk
ZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQogICAgICAgICAgPHRy
IHZhbGlnbj0idG9wIj4gDQogICAgICAgICAgICA8dGQgd2lkdGg9IjE3MCI+PGltZyBzcmM9
Imh0dHA6Ly93d3cubGFiZWwuY28ua3Ivb2ZmaWNlX21haWwvb3BpbWcvcGljMTIwMS5naWYi
IHdpZHRoPSIxNzAiIGhlaWdodD0iMjYiPjwvdGQ+DQogICAgICAgICAgICA8dGQ+PGltZyBz
cmM9Imh0dHA6Ly93d3cubGFiZWwuY28ua3Ivb2ZmaWNlX21haWwvb3BpbWcvcGljMTIwMi5n
aWYiIHdpZHRoPSI0MjgiIGhlaWdodD0iMjYiPjwvdGQ+DQogICAgICAgICAgPC90cj4NCiAg
ICAgICAgICA8dHIgdmFsaWduPSJ0b3AiPiANCiAgICAgICAgICAgIDx0ZCB3aWR0aD0iMTcw
Ij48aW1nIHNyYz0iaHR0cDovL3d3dy5sYWJlbC5jby5rci9vZmZpY2VfbWFpbC9vcGltZy9w
aWMxMjAzLmpwZyIgd2lkdGg9IjE3MCIgaGVpZ2h0PSIxNjMiPjwvdGQ+DQogICAgICAgICAg
ICA8dGQgYmdjb2xvcj0iI0ZGRkZGRiI+DQogICAgICAgICAgICAgIDx0YWJsZSB3aWR0aD0i
NDI4IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQogICAg
ICAgICAgICAgICAgPHRyIHZhbGlnbj0idG9wIj4gDQogICAgICAgICAgICAgICAgICA8dGQg
d2lkdGg9IjIwIiBjbGFzcz0ibGlzdDAxIj48aW1nIHNyYz0iaHR0cDovL3d3dy5sYWJlbC5j
by5rci9vZmZpY2VfbWFpbC9vcGltZy9pbWcxay5naWYiIHdpZHRoPSIyMCIgaGVpZ2h0PSIy
MCI+PC90ZD4NCiAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iNDA4IiBjbGFzcz0ibGlz
dDAxIj7Iq7q4v+sgvsizu7muwLsgvPbDtSwgvPa4uCCw7bC0utC16bKyILq4s7202bDtILv9
sKLH2CANCiAgICAgICAgICAgICAgICAgICAguri8vL/kLiA8YnI+DQogICAgICAgICAgICAg
ICAgICAgIMDOt8Kw+iC4ucC6IL3DsKPAuyC16b+pILjnxKUgvt+x2cfYILChuOm8rSDA2773
x9IgvcOwo7+hIMG7ILT1IMi/wLI8YnI+DQogICAgICAgICAgICAgICAgICAgIMD7wM4gwM/A
uyDHz73DtMKw1CC+7razse6/5D8gRE3A2773wLogwPrI8cfRxdcguMOx4r3KvcO/5C48YnI+
DQogICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgPGZvbnQg
Y29sb3I9IiNGRjY2MDAiPiDA+rfFx8+w7SC9xbzTx8+w1CCw7bC0v6m3r7rQwMcgwaS8usC7
ILTjvsa8rSC/7MbtubAgud+828C7IMOlwNPB9jxicj4NCiAgICAgICAgICAgICAgICAgICAg
sNq9wLTPtNkuIDwvZm9udD48L3RkPg0KICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAg
ICAgICAgIDwvdGFibGU+DQogICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgPGJy
Pg0KICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgIDx0YWJsZSB3aWR0aD0iNDI4
IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQogICAgICAg
ICAgICAgICAgPHRyPiANCiAgICAgICAgICAgICAgICAgIDx0ZCB2YWxpZ249InRvcCIgYWxp
Z249InJpZ2h0Ij48YSBocmVmPSJodHRwOi8vd3d3LmxhYmVsLmNvLmtyL2h0bWwvZG0vcG9z
dGluZy5odG0iIHRhcmdldD0iX2JsYW5rIj48aW1nIHNyYz0iaHR0cDovL3d3dy5sYWJlbC5j
by5rci9vZmZpY2VfbWFpbC9vcGltZy9tb3JlLmdpZiIgd2lkdGg9IjY5IiBoZWlnaHQ9IjEx
IiBib3JkZXI9IjAiPjwvYT48L3RkPg0KICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAg
ICAgICAgIDwvdGFibGU+DQogICAgICAgICAgICA8L3RkPg0KICAgICAgICAgIDwvdHI+DQog
ICAgICAgIDwvdGFibGU+DQogICAgICAgIDx0YWJsZSB3aWR0aD0iNTk4IiBib3JkZXI9IjAi
IGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQogICAgICAgICAgPHRyIHZhbGln
bj0idG9wIj4gDQogICAgICAgICAgICA8dGQgcm93c3Bhbj0iMiI+PGltZyBzcmM9Imh0dHA6
Ly93d3cubGFiZWwuY28ua3Ivb2ZmaWNlX21haWwvb3BpbWcvcGljMTMwMy5qcGciIHdpZHRo
PSIxNzAiIGhlaWdodD0iMTkwIj48L3RkPg0KICAgICAgICAgICAgPHRkPjxpbWcgc3JjPSJo
dHRwOi8vd3d3LmxhYmVsLmNvLmtyL29mZmljZV9tYWlsL29waW1nL3BpYzEzMDIuZ2lmIiB3
aWR0aD0iNDI4IiBoZWlnaHQ9IjI2Ij48L3RkPg0KICAgICAgICAgIDwvdHI+DQogICAgICAg
ICAgPHRyIHZhbGlnbj0idG9wIj4gDQogICAgICAgICAgICA8dGQ+IA0KICAgICAgICAgICAg
ICA8dGFibGUgd2lkdGg9IjQyOCIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBh
ZGRpbmc9IjAiPg0KICAgICAgICAgICAgICAgIDx0ciB2YWxpZ249InRvcCI+IA0KICAgICAg
ICAgICAgICAgICAgPHRkIHdpZHRoPSIyMCIgY2xhc3M9Imxpc3QwMSI+PGltZyBzcmM9Imh0
dHA6Ly93d3cubGFiZWwuY28ua3Ivb2ZmaWNlX21haWwvb3BpbWcvaW1nMWsuZ2lmIiB3aWR0
aD0iMjAiIGhlaWdodD0iMjAiPjwvdGQ+DQogICAgICAgICAgICAgICAgICA8dGQgd2lkdGg9
IjQwOCIgY2xhc3M9Imxpc3QwMSI+v+zG7bmwud+82yhETSnAuyDAp8fRILTru/MgsO2wtMDH
IMHWvNK3zyC1pcDMxbggDQogICAgICAgICAgICAgICAgICAgILG4w+AsIMDOvOK5sLfOILXH
vu48YnI+DQogICAgICAgICAgICAgICAgICAgIMDWtMIgwNq34cDHIMDUt8IgtOvH4CwgseLB
uCDB1rzSt88gtaXAzMW4wMcgu/W/7MbtufjIoyC6r8ivIMDbvve17sC7IDxicj4NCiAgICAg
ICAgICAgICAgICAgICAgw9a9xSCx4rz6t84guavA5cfRIMD8ua6/5L/4tenAzCC/qbevutDA
uyC1tb/NteW4sSCwzcDUtM+02S48YnI+DQogICAgICAgICAgICAgICAgICAgIDxicj4NCiAg
ICAgICAgICAgICAgICAgICAgPGZvbnQgY29sb3I9IiNDQzMzMDAiPjxiPqK6IFdlYi10by1E
QiA6IDwvYj48L2ZvbnQ+PGEgaHJlZj0iaHR0cDovL3d3dy5sYWJlbC5jby5rci9odG1sL2Ri
L2RiX21ha2UuaHRtIiB0YXJnZXQ9Il9ibGFuayI+wMzBqCANCiAgICAgICAgICAgICAgICAg
ICAgsde4ssDHILaxwLsgwffBoiC41MC7ILz2IMDWvcC0z7TZLjxicj4NCiAgICAgICAgICAg
ICAgICAgICAgPGltZyBzcmM9Imh0dHA6Ly93d3cubGFiZWwuY28ua3Ivb2ZmaWNlX21haWwv
b3BpbWcvaW1nMWsuZ2lmIiB3aWR0aD0iMTYiIGhlaWdodD0iMTIiIGJvcmRlcj0iMCI+IA0K
ICAgICAgICAgICAgICAgICAgICDAzsXNs90gvce9w7CjIMHWvNK1pcDMxbi4piC/ory/xsTA
z7fOILi4tem+7iC15biztM+02S48YnI+DQogICAgICAgICAgICAgICAgICAgIDxpbWcgc3Jj
PSJodHRwOi8vd3d3LmxhYmVsLmNvLmtyL29mZmljZV9tYWlsL29waW1nL2ltZzFrLmdpZiIg
d2lkdGg9IjE2IiBoZWlnaHQ9IjEyIiBib3JkZXI9IjAiPiANCiAgICAgICAgICAgICAgICAg
ICAgKL+5IDogaHR0cDovL3RlbC5oYW5taXIuY29tICjH0bnMuKMgwPzIrbn4yKMgsMu79ikp
PGJyPg0KICAgICAgICAgICAgICAgICAgICA8aW1nIHNyYz0iaHR0cDovL3d3dy5sYWJlbC5j
by5rci9vZmZpY2VfbWFpbC9vcGltZy9pbWcxay5naWYiIHdpZHRoPSIxNiIgaGVpZ2h0PSIx
MiIgYm9yZGVyPSIwIj48L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICA8Yj48Zm9udCBj
b2xvcj0iI0NDMzMwMCI+orogtaXAzMW4IMDUt8I8L2ZvbnQ+PC9iPjxicj4NCiAgICAgICAg
ICAgICAgICAgICAgPGZvbnQgY29sb3I9IiNDQzMzMDAiPjxiPqK6IMHWvNIgtvO6pyDD4rfC
PC9iPjwvZm9udD48YSBocmVmPSJodHRwOi8vd3d3LmxhYmVsLmNvLmtyL2h0bWwvZG0vbGFi
ZWxfcHJ0Lmh0bSIgdGFyZ2V0PSJfYmxhbmsiPiANCiAgICAgICAgICAgICAgICAgICAgPC9h
Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgPGZvbnQgY29sb3I9IiNDQzMzMDAiPjxiPqK6
ILv1v+zG7bn4yKMguq/IrzwvYj48L2ZvbnQ+PC90ZD4NCiAgICAgICAgICAgICAgICA8L3Ry
Pg0KICAgICAgICAgICAgICA8L3RhYmxlPg0KICAgICAgICAgICAgICA8dGFibGUgd2lkdGg9
IjQyOCIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KICAg
ICAgICAgICAgICAgIDx0cj4gDQogICAgICAgICAgICAgICAgICA8dGQgdmFsaWduPSJ0b3Ai
IGFsaWduPSJyaWdodCI+PGEgaHJlZj0iaHR0cDovL3d3dy5sYWJlbC5jby5rci9odG1sL2Ri
L2RiX21haW4uaHRtIiB0YXJnZXQ9Il9ibGFuayI+PGltZyBzcmM9Imh0dHA6Ly93d3cubGFi
ZWwuY28ua3Ivb2ZmaWNlX21haWwvb3BpbWcvbW9yZS5naWYiIHdpZHRoPSI2OSIgaGVpZ2h0
PSIxMSIgYm9yZGVyPSIwIj48L2E+PC90ZD4NCiAgICAgICAgICAgICAgICA8L3RyPg0KICAg
ICAgICAgICAgICA8L3RhYmxlPg0KICAgICAgICAgICAgPC90ZD4NCiAgICAgICAgICA8L3Ry
Pg0KICAgICAgICA8L3RhYmxlPg0KICAgICAgICA8dGFibGUgd2lkdGg9IjU5OCIgYm9yZGVy
PSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KICAgICAgICAgIDx0cj4N
CiAgICAgICAgICAgIDx0ZCBiYWNrZ3JvdW5kPSJodHRwOi8vd3d3LmxhYmVsLmNvLmtyL29m
ZmljZV9tYWlsL29waW1nL21saW5lX2guZ2lmIiB2YWxpZ249InRvcCIgaGVpZ2h0PSIxIj48
aW1nIHNyYz0iaHR0cDovL3d3dy5sYWJlbC5jby5rci9vZmZpY2VfbWFpbC9vcGltZy9pbWcx
ay5naWYiIHdpZHRoPSIxIiBoZWlnaHQ9IjEiPjwvdGQ+DQogICAgICAgICAgPC90cj4NCiAg
ICAgICAgPC90YWJsZT4NCiAgICAgICAgPHRhYmxlIHdpZHRoPSI1OTgiIGJvcmRlcj0iMCIg
Y2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCiAgICAgICAgICA8dHIgdmFsaWdu
PSJ0b3AiPiANCiAgICAgICAgICAgIDx0ZCBjbGFzcz0ibGlzdDAxIiBjb2xzcGFuPSIyIj4N
CiAgICAgICAgICAgICAgPGRpdiBhbGlnbj0iY2VudGVyIj48Zm9udCBjb2xvcj0iI0ZGNjY2
NiI+PGJyPg0KICAgICAgICAgICAgICAgIMDMuN7AzyDB1rzStMIgwM7FzbPdILytx87AuyDF
68fYILz2wf3Hz7+0wLi45ywgwMy43sDPIMHWvNIgv9y/obTCIL7utrDH0SDBpLq4tbUgsKHB
9rDtIMDWwfYgvsq9wLTPtNkuPGJyPg0KICAgICAgICAgICAgICAgILT1wMy78yC43sDPwLsg
v/jEoSC+ysC4vcO46SC89r3FsMW6zrimIMWsuK8gx9jB1ry8v+QuIMHBwLogx8+35yC6uLO7
vLy/5C48YnI+DQogICAgICAgICAgICAgICAgPGZvbnQgY29sb3I9IiNDQzMzMDAiPjxicj4N
CiAgICAgICAgICAgICAgICBbPGEgaHJlZj0iaHR0cDovL3d3dy5jcnVzYWRlLmNvLmtyL3Jl
amVjdC9yZWplY3QucGhwP2lkPTIxMzUmYXV0aD05YTQ5YTI1ZDg0NWE0ODNmYWU0YmU3ZTM0
MTM2OGUzNiZtYWlsPXhtbC1zaWdAcHl0aG9uLm9yZyZtb2RlPXdyaXRlIj689r3FsMW6zjwv
YT5dIDxicj4NCiAgICAgICAgICAgICAgICA8L2ZvbnQ+PC9mb250PjwvZGl2Pg0KICAgICAg
ICAgICAgPC90ZD4NCiAgICAgICAgICA8L3RyPg0KICAgICAgICA8L3RhYmxlPg0KICAgICAg
ICA8dGFibGUgd2lkdGg9IjU5OCIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBh
ZGRpbmc9IjAiPg0KICAgICAgICAgIDx0cj4NCiAgICAgICAgICAgIDx0ZCB2YWxpZ249InRv
cCIgYmdjb2xvcj0iIzk5OTk5OSIgaGVpZ2h0PSIxIj48aW1nIHNyYz0iaHR0cDovL3d3dy5s
YWJlbC5jby5rci9vZmZpY2VfbWFpbC9vcGltZy9pbWcxay5naWYiIHdpZHRoPSIxIiBoZWln
aHQ9IjEiPjwvdGQ+DQogICAgICAgICAgPC90cj4NCiAgICAgICAgPC90YWJsZT4NCiAgICAg
ICAgPHRhYmxlIHdpZHRoPSI1OTgiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxw
YWRkaW5nPSIwIj4NCiAgICAgICAgICA8dHI+DQogICAgICAgICAgICA8dGQgY2xhc3M9Imxp
c3QwMSI+PGltZyBzcmM9Imh0dHA6Ly93d3cubGFiZWwuY28ua3Ivb2ZmaWNlX21haWwvb3Bp
bWcvYm90dG9tLmdpZiIgd2lkdGg9IjU5OCIgaGVpZ2h0PSI2MCI+PC90ZD4NCiAgICAgICAg
ICA8L3RyPg0KICAgICAgICA8L3RhYmxlPg0KICAgICAgICANCiAgICAgIDwvdGQ+DQogICAg
ICA8dGQgYmdjb2xvcj0iIzk5OTk5OSIgYWxpZ249InJpZ2h0IiB3aWR0aD0iMSI+PGltZyBz
cmM9Imh0dHA6Ly93d3cubGFiZWwuY28ua3Ivb2ZmaWNlX21haWwvb3BpbWcvaW1nMWsuZ2lm
IiB3aWR0aD0iMSIgaGVpZ2h0PSIxIj48L3RkPg0KICAgIDwvdHI+DQogIDwvdGFibGU+DQo8
L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4=

------=_NextPart_000_0077_01C0F44A.93A49C00--

From hanbay3@hotmail.com  Thu Feb 28 11:40:41 2002
From: hanbay3@hotmail.com (HanBay)
Date: Thu, 28 Feb 2002 20:40:41 +0900
Subject: [XML-SIG] [堡 绊] 秦寇背器甸狼 茄惫侥前 辆钦碱俏隔
Message-ID: 

:+: 茄海捞 全焊皋老 :+:

            + 
            努腐窍矫搁 官肺 历锐 磊丰俊辑 蓖窍狼 捞皋老 林家啊 昏力邓聪促   ⒀ 荐脚芭何