OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Fwd: Fwd: [xml-dev] Streaming Transformations for XML

[ Lists Home | Date Index | Thread Index ]
  • To: XMLDEV <xml-dev@lists.xml.org>
  • Subject: Fwd: Fwd: [xml-dev] Streaming Transformations for XML
  • From: Jandia Cyril <cjandia@logfi.fr>
  • Date: Fri, 15 Feb 2002 10:14:29 +0100
  • Importance: Normal


Hi all, Petr,

> From : Petr Cimprich [mailto:petr@gingerall.cz]
> To : Jandia Cyril
> Subject : Re: Fwd: [xml-dev] Streaming Transformations for XML
>
> Cyril,
>
> I will try to create at least a plain list of supported instructions and
> axes, so that we have something to discuss. This could be a core of a
> future language specs. I will send you a copy ASAP.

Fine, thanx!

> Some questions now :)
> What are your plans? Are you considering to implement STX (or whatever
> will be the name) in ESPX?

Well, in fact, even before you first talked about that STX idea on the list,
I was contemplating for some time to add sth like a simplified (subset)
version of XPath (see this [tinyxsl-idea]) to my TinyXSL.

[tinyxsl-idea]
  http://www.cjandia.com/2001/espx-tinyxsl/#xpath-subset

Basically, I wanted to enhance TinyXSL's "select='...'" operator
capabilities (which are, let me remind you, very limited for now - since
they merely rely on ESPX's own capabilities of its DOM(-like, again!) API).

For various reasons, notably the overhead that it would probably imply on
current ESPX processing, I didn't push the idea further - but I imagine it
is more realistic w/ a processing model occurring in the context of SAX axes
rather than of XPath's... so read on :

Now, about a game plan, since you came w/ your STX, which is -I believe-
interesting on its own (processing model, SAX axes, maybe RegExps for the
"character::" axe, etc), I think I could easily take advantage of that
existing TinyXSL's implementation to propose you(us) a first,
test-of-concept, reference implementation of STX the same way (i.e, how I
first wrote ESPX, surfacing a very simplified DOM-like ECMAScript object
model, and then, wrote TinyXSL which use the latter).

That is, either :

1) (preferred)
  current ESPX
  => rewrite of ESPX with SAX API added
  => STX processor (from scratch)
or
2) (less clean, but quicker maybe)
  current TinyXSL
  => modified TinyXSL emulating needed SAX axes (modifying the way it
performs ESPX's mini-DOM crossing)
  => STX processor

> And what about TinyXSL? Or do you see TinyXSL and STX fully mergable?

Sure, at least if -as far as an ECMAScript implementation of either or both
is acknowledged to be useful.

Then, I see no reason to either merge them or develop STX in parallel (but
preferably building up from ESPX and/or TinyXSL in either cases, instead of
a complete rewrite from scratch - see above).

> And, yes I like the RegExp idea at the first glance. We just have to
> decide, whether to use RE when matching templates or inside templates
> (stx:if) or both.

Right, that's it.

> [...]
> Petr Cimprich
> Ginger Alliance
> www.gingerall.com

Regards,
Cyril Jandia
http://www.cjandia.com/
Author of ESPX/TinyXSL
http://www.cjandia.com/2001/espx-tinyxsl/




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS