Fw: [SML] Whether to support Attribute or not?

[Eric Bohlman]

On Mon, 29 Nov 1999, Oren Ben-Kiki wrote:

> SSLT would have simplified XPath syntax, since there is no issue of
> attributes. If SSLT is to be written in SML, the XSLT syntax would have to
> be reworked, but this is pretty mechanical - in fact it could be done
> automatically both ways (using an XSLT stylesheet :-). So far, this doesn't
> gain much. An XSLT processor is complicated enough that it doesn't have much
> to gain from SML.
> 
> Making SSLT streaming-only on the other hand, is an interesting notion. I
> was always uncomfortable with XSLT's choice of requiring random access to
> the input. There are many transformation jobs where the input is much larger
> then the output - orders of magnitude larger.

Definitely.  Let's talk not just about XSLT translation, but about
querying in general (which is likely to be based on XPATH syntax and the
same sort of data model as XSLT).  For example, the TEI crowd is probably
going to want the ability to extract fragments from large corpora of text
marked up potentially at the syllable level.  That's not going to be
practical if you're restricted to a data model that requires building a
tree for the entire source document.

I would say that developing a data model to support streaming
query/extraction for XML is a far more worthwhile endeavor than developing
a stripped-down data syntax whose main purpose is to allow script kiddies
(not to be confused with Desperate Perl Hackers) to repeatedly cargo-cult
parsers so that their bosses don't get freaked out by the presence of NIH
code, some of which might be (gasp!) Open Source.

> 
> S(treaming)SLT would be different from XSLT in the following ways:
> 
> - A template would be completely responsible for all the sub-tree below the
> element it matches;
> - A template would be limited to specifying a single pass on this sub-tree
> (i.e., a single call to apply-templates, for-each, etc.).
> - Therefore, side effects (variable assignment) would be allowed.

As I see it, you'd need a way of giving names to path expressions and
their result sets, and a way of making one path expression conditional on
the success of another.  Thus a path expression that goes down the
conceptual tree along the child:: axis, then back up the tree along
Ancestor::, and then sideways along following-sibling could be replaced
with three child::-only path expressions that would have to match in
sequence (though not the same order as they would appear in the full XPath
expression), each of which would "squirrel away" the conceptual nodes that
matched.  The idea is to limit the "running storage" required to a stack
of element names encountered along the current branch of the conceptual
tree and the text content of the current element (along with any
squirreled-away data).

An interesting question is whether a full XPath expression could be
automatically decomposed into a sequence of "sequential-path" expressions.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)