Walter Dörwald walter@livinglogic.de
Thu, 17 Oct 2002 21:47:25 +0200

Uche Ogbuji wrote:

>>On Wed, Oct 16, 2002 at 07:39:14PM +0200, Walter Dörwald wrote:
>>>   * XIST now has namespace support for parsing and publishing.
>>>     Namespace support is even available for entities and
>>>     processing instruction.
>>  Are you trying to reinvent XML ? Namespace support for PI ???
>>What's that ?
> I have a similar question.  I did mention XIST in
> http://www.xml.com/pub/a/2002/09/18/py.html

I noticed that! ;)

> But now I wonder whather I missed something fundamental about it.
> What do the comments on namespaces in the announcement mean?
 > What is the basic relationship between XIST and XML/XML NS?

For standard DOMs you have one element class. The element type
is available as an additional attribute on the element class

In XIST every element type maps to a separate element class, and
every element that is of this element type is an instance of the
appropriate class (which is derived from the element base class).

When you do a "from ll.xist.ns import html" you're defining
93 element classes for all the element types defined in XHTML 1.0
and you're telling XIST that these classes all belong
to the namespace with the name "http://www.w3.org/1999/xhtml".

When you're importing ll.xist.ns.ihtml you're defining the
version of HTML used for DoCoMo's i-mode (with the
namespace name "http://www.nttdocomo.co.jp/imode" (which
is made up, because AFAICT there is no official namespace

Both namespaces contain an element type "a" (but with different
attributes), so both modules define a class "a".

Now when XIST parses an XML file, it must know which class to
instantiate. In versions prior to 2.0 this was more or less
non-deterministic (it happened to be the element class that
was defined last), but in XIST 2.0 namespaces are used
for that, i.e.

<a xmlns="http://www.w3.org/1999/xhtml"/>

will instantiate ll.xist.ns.html.a and

<a xmlns="http://www.nttdocomo.co.jp/imode"/>

will instantiate ll.xist.ns.ihtml.a.

Mapping element types to classes seems to be totally useless,
until you start to define your own new element classes:
Tree transformation logic that is written with template
elements in XSLT is written with methods in XIST. For example
the XSLT rule

<xsl:template match="bold">

can be written in XIST as:

from ll.xist.ns import html
class bold(xsc.Element):
    empty = False
    def convert(self, converter):
       return html.b(self.content.convert(converter))

So you can program you XML transformations in Python
and use all the benefits we know and love. ;)

We use this for making the syntax for JSP files XML-compatible:

JSP defines several syntaxes for embedding executable Java
code in HTML templates. <% scriptlet %> works like <?php scriptlet?>,
i.e. it embeds the scriptlet literally in the generated
servlet. <%= expression %> generates Java code that
output the expression.

Unfortunately this syntax is not XML compatible. (There's a
XML compatible variant, but the last time we looked this
wasn't supported by all application servers.)

With XIST this problem can be solved rather easily. Define
scriptlet and expression as processing instructions and
overwrite the publish method, which is responsible
for emitting the resulting "XML" string:

class scriptlet(xsc.ProcInst):
    def publish(self, publisher):
       publisher.publish(u"<% ")
       publisher.publish(u" %>")

class expression(xsc.ProcInst):
    def publish(self, publisher):
       publisher.publish(u"<%= ")
       publisher.publish(u" %>")

So you can write your JSP expressions as:
<?jsp:expression 17+23+42?>
After conversion by XIST this will be output as:
<%= 17+23+42 %>

Granted, this isn't XML any more, but it's nonetheless
very useful.

Apart from that, XIST is just a tool for generating
extended XML trees that come with their own
transformation methods.

Sorry for the long rant, I hope this explains what can
be done with XIST.

For more information you might want to read the HOWTO at:

    Walter Dörwald