Mailing List Archive

Parsed XML Requirements Feedback
Hello All!

First off, many thanks to Martijn for taking on Parsed XML - this product
even with its flaws has been too useful not to use and deserves a lot of love.

We have been using Parsed XML 1.1b1 on sites using 2.3/1.5.2 and 2.4/2.1.
For the most part, I have no bonds to 2.3/1.5.2, and would favor seeing
Parsed XML development using the 2.4/2.1 releases.

We've used Parsed XML largely as a container for content, which we map to HTML
using DTML, Python DOM, and most recently ZPT calls.

Visually editing the DOM tree via the Zope Management Interface has not
really been useful to us. Honestly, IMHO there are better tools for editing
XML (Emacs, XML Spy, ArborText, etc.) than ZMI, especially through a DOM tree.

On the other hand, making the DOM tree a HTML form with text boxes populated
with the node values could be very useful.

Fixing bugs with Parsed XML is high on my wish list:

* Copy and Paste of Parsed XML objects is buggy (though Karl mentioned that
a fix was made but not released a while back).

* Editing of Parsed XML objects though FTP doesn't work.

* Instantiation of a Parsed XML object by importing a file requires that
you explicitly type an id for it, rather than using the existing file
name for the id.

* Performance can always improve.


Questions on where Parsed XML is going, esp. with Zope pushing Zope Page Templates (ZPT):

Will Parsed XML have XSLT support? Will it really matter if
integration with ZPT is good enough? So far in working with Parsed XML and ZPT,
we've gotten this far:

ZPT making DOM calls to Parsed XML Object: Good
ZPT calling Python script with DOM calls to Parsed XML Object: Good

What is not clear is how to create a ZPT-style method (arguably not possible,
since ZPTs are objects) to directly render a Parsed XML object, like a
DTML-method:

object/viewXML
^ ^
| |
parsed xml dtml method


Anyone out there with some insights into this?


Thanks!


-Charles
Re: Parsed XML Requirements Feedback [ In reply to ]
Charles Y. Choi wrote:

>
> Will Parsed XML have XSLT support? Will it really matter if
> integration with ZPT is good enough? So far in working with Parsed XML
> and ZPT,


Tying ParsedXML to XSLT is very easy (well, it's easy once you've
installed 4Suite, but that's another matter). I've done it already as
an External Method, but I want to come up with a better user interface.
I'm looking at Martijn's XPath Methods for ParsedXML as a model for
adding XSLT to ParsedXML. The tricky bit is that, a) A single XSLT
object may be used for multiple XML objects, and b) A single XML object
may be used with multiple XSLT objects.

What I'm thinking right now is this:

folder -+
+- XMLinstance (ParsedXML)
+- XSLstylesheet (ParsedXML)

so the path to the XML instance would be:

/root/folder/XMLinstance

and to apply the stylesheet:

/root/folder/XMLinstance/XSLstylesheet

Any comments on that interface?


> What is not clear is how to create a ZPT-style method (arguably not
> possible,
> since ZPTs are objects) to directly render a Parsed XML object, like a
> DTML-method:


Render how? As XML? You should be able to do that directly, and you
can do it indirectly with the PT_XPath add-on for ZPT (print the results
of the path expression /*), which should also work with the XPath
Methods for ParsedXML (as long as the XML instances don't use namespaces).

HTH

--Dethe

--

Dethe Elza (delza@burningtiger.com)
Chief Mad Scientist
Burning Tiger Technologies (http://burningtiger.com)
Living Code Weblog (http://livingcode.ca)
Re: Parsed XML Requirements Feedback [ In reply to ]
Charles Y. Choi wrote:
> First off, many thanks to Martijn for taking on Parsed XML - this product
> even with its flaws has been too useful not to use and deserves a lot of
> love.

Thanks! At least if you mean me and not the Other Martijn. :)

[snip]
> We've used Parsed XML largely as a container for content, which we map to
> HTML using DTML, Python DOM, and most recently ZPT calls.

Is the mapping to HTML through DTML fast enough currently? (should get
faster in the future though with my patch)

> Visually editing the DOM tree via the Zope Management Interface has not
> really been useful to us. Honestly, IMHO there are better tools for editing
> XML (Emacs, XML Spy, ArborText, etc.) than ZMI, especially through a DOM
> tree.

I like the ability to type in a bit of XML through the web. The tree
view itself isn't that useful to me either, though I imagine it would
be useful in case of large documents, where I want to edit only a small
section.

> On the other hand, making the DOM tree a HTML form with text boxes populated
> with the node values could be very useful.

I'm having trouble envisioning what such a form should look like, could
you give more details?

> Fixing bugs with Parsed XML is high on my wish list:
>
> * Copy and Paste of Parsed XML objects is buggy (though Karl mentioned that
> a fix was made but not released a while back).

I hadn't heard of this one before -- see how much I've used them! :)
Let's hope the fix is in the CVS. If not, we can always email Karl and
ask.

> * Editing of Parsed XML objects though FTP doesn't work.

I'd be very happy to see patches for this. :)

> * Instantiation of a Parsed XML object by importing a file requires that
> you explicitly type an id for it, rather than using the existing file
> name for the id.

This seems to be the case in other Zope objects as well. Anyway, patches
are welcome if this is actually possible (there must be a reason why
some of these other objects don't do this).

> * Performance can always improve.

The next release should have increased performance for access through
Zope, though the raw Python performance of the underlying DOM won't
change.

> Questions on where Parsed XML is going, esp. with Zope pushing Zope Page
> Templates (ZPT):
>
> Will Parsed XML have XSLT support?

I hope so; I'm not the one developing it but Dethe is looking into it,
as you saw in his reply.

> Will it really matter if integration with ZPT is good enough?

I think XSLT support is important. I haven't used XSLT myself yet, but
I imagine usages which are harder to do with ZPT. With XSLT you could
potentially report on *any* underlying data that is exposed to a DOM,
such as the mythical ZDOM we're looking into. If the ZDOM exposes a
comprehensible DOM view on underlying Zope objects, it could be possible
that using XSLT becomes one of the easiest ways to generate HTML for
complicated object structures.

> So far in working with Parsed XML and
> ZPT, we've gotten this far:
>
> ZPT making DOM calls to Parsed XML Object: Good
> ZPT calling Python script with DOM calls to Parsed XML Object: Good
>
> What is not clear is how to create a ZPT-style method (arguably not
> possible,
> since ZPTs are objects) to directly render a Parsed XML object, like a
> DTML-method:
>
> object/viewXML
> ^ ^
> | |
> parsed xml dtml method
>
> Anyone out there with some insights into this?

Hm, I haven't tried this yet, but I don't quite understand what the
difficulties would be. ZPT objects are acquired, right?

Regards,

Martijn
Re: Parsed XML Requirements Feedback [ In reply to ]
Martijn Faassen <faassen@vet.uu.nl> writes:

> > * Copy and Paste of Parsed XML objects is buggy (though Karl mentioned that
> > a fix was made but not released a while back).
>
> I hadn't heard of this one before -- see how much I've used them! :)
> Let's hope the fix is in the CVS. If not, we can always email Karl and
> ask.

ParsedXML instances were losing some Zope attributes, such as ID,
between txns, and that was showing up during cut and paste. If that's
what you're talking about, it should be fixed. There are some tests
for Zope interactions such as that, so it should be easy to add one
that demonstrates any other problems.

> > * Editing of Parsed XML objects though FTP doesn't work.
>
> I'd be very happy to see patches for this. :)

There's commented out stubs in the code that I never got around to
filling out.

--
Karl Anderson kra@monkey.org http://www.monkey.org/~kra/
Re: Parsed XML Requirements Feedback [ In reply to ]
Dethe Elza <dethe@burningtiger.com> writes:

> Charles Y. Choi wrote:
>
> >
> > Will Parsed XML have XSLT support? Will it really matter if
> > integration with ZPT is good enough? So far in working with Parsed XML
> > and ZPT,
>
>
> Tying ParsedXML to XSLT is very easy (well, it's easy once you've
> installed 4Suite, but that's another matter). I've done it already as
> an External Method, but I want to come up with a better user interface.

Tying ParsedXML to XSLT by printing XML and giving that text to the
processor is easy, but inefficient. I presume that you didn't get
4Suite's XSLT processor to work on ParsedXML's DOM - they're moving
away from the DOM and towards a more efficient storage. PyXML intends
to be able to do this for any compliant DOM, however, and that might
have gotten closer while I wasn't looking.

> I'm looking at Martijn's XPath Methods for ParsedXML as a model for
> adding XSLT to ParsedXML. The tricky bit is that, a) A single XSLT
> object may be used for multiple XML objects, and b) A single XML object
> may be used with multiple XSLT objects.
>
> What I'm thinking right now is this:
>
> folder -+
> +- XMLinstance (ParsedXML)
> +- XSLstylesheet (ParsedXML)
>
> so the path to the XML instance would be:
>
> /root/folder/XMLinstance
>
> and to apply the stylesheet:
>
> /root/folder/XMLinstance/XSLstylesheet
>
> Any comments on that interface?

That's what I had XSLTemplate doing
(http://www.zope.org/Wikis/zope-xml/XSLTemplate). You can give the
product the IDs of your sheets and source, or you can acquire the
product from your source and its sheets will transform it. You can
also acquire the product from a subnode of your source, very cool. To
pass several XSLT sheets, you have tell the processor their IDs and
have the main sheet use them as params.

XSLTemplate was quite alpha when I left it. It used sab-pyth when it
was released, but the CVS version used 4Suite's transformer when I
last touched it.

I think that XSLTemplate illustrates some current drawbacks for Zope
and XML. You want some cacheing of the XML - you don't want to
generate the XML from the ParsedXML each time you transform. Right
now cacheing is really aimed at the web page level, which works fine
if it lets you avoid transforming altogether because your server
cached the output, but loses otherwise. We need a ZODB cache to
complement the RAM cache. I was cacheing the XML within XSLTemplate,
but I yanked it out in CVS - half the code was about cacheing and I
thought it was a net loss. The cache manager framework is really
there, just needs someone to want a ZODB version.

--
Karl Anderson kra@monkey.org http://www.monkey.org/~kra/