Re: [XSLT-Megalogichst] taglib application order

[Tagunov Anthony <at...@nnt.ru>]

On Sun, 11 Mar 2001 11:26:08 -0500 (EST), Donald Ball wrote:

>On Sun, 11 Mar 2001, Robin Green wrote:
>
>> Donald wrote:
>> > >logicsheets aren't "run" before or after one another - the code which
>> >they
>> > >generate is run top-down through a mix of instructions they all generate.
>> > >they're applied in a certain order by the c1 xsp engine, but i think it
>> > >could just as easily work by merging all of the logicsheets into one big
>> > >stylesheet and re-applying it that until no nodes in any of the
>> >logicsheet
>> > >namespace uris are left. hmm, i wonder, is that true?
>>
>> No - Tagunov's example of including makes a good counterexample. Since the
>> second logicsheet acts on the output of the first (the "includer" one).
>
>er, i disagree, since you're re-applying the mega-logicsheet until no
>nodes in any of the logicsheet namespace uri's are left - that allows the
>output of one logicsheet to invoke another logicsheet.

Well, it's ceratanly a rich idea and it goes in the direction of removing the order
of application-order-independency for XSLT-based stylesheets.

And it is a very important point here that Donald says UNTILL THERE ARE
NO NODES OF THE LOGICSHEET NAMESPACE.

If we omit this, and say until NO NEW ELEMETNS HAVE APPEARED we'll have 
a mess i describe bellow:
                    
                                       - o -

I should remark that if the taglibs are allowed to react to elements out
of their namespace
(going to the ABC-classification that i have attempted on another thread
this type-C interaction.
-- type-B is interaction when each tagilb may only
   react to tags in it's own namespace, 
-- type-C is interaction when taglib B may react to
   elements out of it's namespace
   under type-C i tried to discriminate
----type-C.4 when tablib B is allowed to
     react to child elements of an element
     in its namespace (with  
     <B:foo><a>1</a><b>2</b></B:foo><c>4</c>
     taglib B in C.4 would be allowed to react to <a> elems, but not to <c>
----type-C.3 when taglib B is allowed to
     react to ANY element in the stylesheet, and a reasonable(?) example
     was reacting to something under <xsp:structure> element
)

then simply merging XSLT stylesheets will yield undesirable results.
in C.3 just imagine a stylesheet that adds a child element to <xsp:structure>!
It will run iternally just enlarging the resulting XML!

Here we hit problems similar to those studied in DATALOG-related research
(they have a prolog-style language, but it is computed into width not in
depth like prolog. they limit to much simplier transformations then XSLT,
they have something like a set of points in multidementional space,
points are like a("1","2","abc"), b("2","4") which can be easily seen as
("a","1","2","abc") ("b","2","4"). They have an initial set and
rules for adding new tuples, like ("a","1",x),(x,"2")->("z","1",x).
Every iteration adds new tuples to the set according to production rules.
With rules like this the process is guaranteed to be finite, but if we
have rules like ("a","1",x), not(x,"2")->("z","1",x) then no finitness is
guaranteed in the general case. XSLT transforms maybe converted
to smth similar to those model, but as it can be guessed no finitness is
guranteed for such process (see the above example with adding
a new child somewhere in the tree -- the process is infinite, the
set is growing, growing, growing..)
                    - o -
This horror happens whenever we run "until no new elements get added"
But it is easily seen that similar effects may appear even if we run
"until no elemnts in the taglib namespace" are present:

imagine that taglibB does C.3-type interaction, adds an child element
somewhere in the tree not in place of elements in it's namespace,
say adds to <xsp:structure>.

Imagine that we have <page><A:foo/><B:foo/></page>
document and apply two taglibs to it, A and B. And
A does <A:foo/>--><B:foo/>.

Then at the first megalogicsheet application we get those C.3 child
appended to <xsp:structure> once, and then the megalogicsheet
gets applied again (there's a brand-new <B:foo/>!). And the child gets
appended again.
                    - o -
May be limiting (by force!) the transformations that a XSLT-style taglib
may perform on the source XML is limited to C.2 we can avoid such clumsy
stuff?
                    - o -
Clear that in B model such problem does not exist.
                    - o -
One more trouble with mega-logicsheet already in C.4: imagine we have
<A:foo>
  <B:foo/>
</A:foo>
imagine we merge XSLTs according to logisheets semantics template for
<B:foo/> should get applied first and according to XSLT semantics
template for <A:foo/> will get applied first and the template for <B:foo/>
will get applied only if template for <A:foo/> allowes that.
(In C.4 we allow XSLT template for A:foo to react to any children of <A:foo>
and probably those that are actually calls to taglib B.
                    - o -
The conclusion to this all is that some limitations on 
taglibs and what tags they may react to should be
imposed to allow order-safe taglib usage in general
and mega-logicsheet model in particular.
                    - o -
A justification for this all being sent to XSPDev is that
AxKit of implementing taglibs also imposes 
_IMPLICIT_ (as far as i understand) limitations on 
taglibs of such nature.

An no matter weather, say in Cocoon, if the taglibs
continue to be XSLT-based or AxKit-style (or both
being allowed as options, why not ;-), to allow
proper taglib interoperations limitations should be imposed
on types of interactions that may happen between
taglibs. The (A),(B),(C.3),(C.4) classification is an
attempt to dig in this direction.

Best regards, Tagunov Anthony