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

["Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>]

On Sat, 27 Nov 1999, Paul Tchistopolskii wrote:
> S-XSLT should be written anyway. XT will hardly fit into
> cell phone ;-)
>
> S-XSLT processor should be much easier to write than
> it was to write XT ( the same is with SML parser, S-SAX, e t.c.):

Question: how far does this go? If we have SSLT, would we also have SLink,
SSchema, SPath (well, obviously we'll have that; no matching on attributes),
...? How about SHTML?

Admittedly it is fun having the X-people do some work, then come along a
year or two later, with perfect hindsight, to create a better spec. Besides,
the deserve it, since they have done the same to SGML :-)

Is this a way to resolve the problem of trying to build specs in Internet
time - "must get it out the door, we'll re-think it in the next generation"?
I have mixed feelings about this...

Clark C. Evans <clark.evans@xxxxxxxxxxxxxxxxxxxx> wrote:
> I'm all for this; the SSLT definition should be
> stream-only; in otherwords, it should not require
> random access to the entire SML stream.

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.

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.

Sorting and numbering always require another "pass". We can either:

- Keep the XSLT model, which requires a buffer large enough to hold all the
sorted input tree fragments.
- Change the model so that sorting would be done on output tree fragments.
This reduces the language power in some ways.
- Disallow sorting altogether.

The second option is based, again, on the assumption that the result tree is
smaller then the input tree. Its consequences are:

- Templates are _always_ called in document order, even in sorted
invocations (important due to side effects).
- The computation of 'position' operation in sorted invocations would be
delayed until the sorting pass.

Doing a delayed 'position' computation would complicate the SSLT processor,
unless the use of this function is restricted to being embedded inside the
output tree. In particular, it would be illegal to use it in a condition or
in side effects. This way the SSLT processor could simply do the embedding
as part of the sorting pass.

Have fun,

    Oren Ben-Kiki


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list