RE: alternating tags in a list?

[Guy_Murphy@xxxxxxxxxx]

Hi.

I think I understand your intent better this time round than I did
originaly. And I wish I could have expressed myself as well as you have.

I think you've come to the crux of certianly my feeling regarding XSL. I
love the pattern matching, but I want more flexibility from that point
than XSL offers, as your right, at this point for 90% of such matches, the
simple declaritive model will fufice and I can simply specify output.
However,
the are many occasions when I may need to break out of this declaritive
mould and resort to imperitive actions. This might not be ideal, pure, well
considered, elegant or whatever, but in many cases it's expediant.

In real-world commercial development there often isn't the schedule to go
round the houese and do things as they "should" be done ideally.

It would seem to me that if ECMAScript is included in the spec of XSL then
the above is no longer a problem, as I can "escape" to script.

For myself the point is moot, as I'm convinced MS will support
ActiveScripting in their implimentation of XSL regardless of the W3C
including it or not, and as my development is on NT Boxes with IIS, I'll
simply go for the MS XSL as a way of getting rid of alot of ASP.

Don't get me wrong, I am warming increasingly to the idea of XSL as a
declaritive language, and would like to see XSL facilitate the avoidance of
breaking out to script wherever possible, but at the end of the day, XSL
isn't a religious persuit for me, so all I care is that it perfoms the taks
necessary in getting data in the for of XML into the renderable form I need
in HTMLlike XML, and personaly I don't care what axioms of Computer Science
recieved wisdom have to be sacrificed on the alter to achieve this.

Can you expand upon what way you think might be good in the ACTION part of
what you describe bellow? I'm interested to know exactly what you mean
here.

Cheers
     Guy.





xsl-list@xxxxxxxxxxxxxxxx on 12/17/98 01:31:04 AM

To:   xsl-list@xxxxxxxxxxxxxxxx
cc:    (bcc: Guy Murphy/UK/MAID)
Subject:  RE: alternating tags in a list?




Hi Paul,
Thread 1 -----------------------------------------------
> If you would have a tool with kind of events fired on pattern match like
for
> instance each time the <paragraph> </parapgraph> element is encoutered
you
> would have an event fired and the corresponding event handler called.
Would
> that be an interessting tool?
This is an excellent idea, but I think that web browsers already have it
built in already. Isn't there some event (perhaps "OnLoad()")that is
triggered for each element as it is loaded into a browser? If so, then you
could solve a problem like coloring rows based on the digits of pi like
this:
<xml:template ...>
   <row onLoad="this.bgcolor=CalculateRowColor( this )">...</row>
</xml:template>

Reply ---------------------------------------------------
What I meant is:
Premises:
a) XML document with only semantic tags.
b) a transformation script that will transform this XML into a displayable
thing.
c) components based on VTBL interfaces are not necessarily Microsoft
dependant :-) (An example is the FLUKE Oskit from University of Utah)

Hypothesis:
It seems that languages like XSL or DSSSL are rule based. Or based on:
<Pattern or rule>
      |______ <action>
So we have two parts like we already have on production systems found in
expert systems.
So, it seems that the rule or pattern part is useful. Why, because we don't
have to scan the whole grove or document object hierarchy with loops and
other similar constructs. Thus, it seems that everybody agrees that this
part is useful.
the problem is with the <action> part. Theorists see no problems but
pragmatist see problems of flexibility. So then, why not have the <action>
part defined as a script then? Even better, you could pick the script of
your choice by invoking the script engine of your choice that does the best
job for that particular context. the script could then be given an API or
set of object to create the appropriate Flow object hierarchy or whatever
the layout pattern used.


Thread 2 ------------------------------------------------------
> So the tool would do pattern match and for each element would fire an
event
> and the corresponding event handler called. the event handler could be
> written with a script language such as: EcmaScript, VBScript, PerlScript,
> PythonScript. The event handler would receive an object (i.e. a flow
object)
> having a property set attached to it. The event handler could either use
the
> property set a set values (including the object's type). Then the scrip
> would be able to set the kind of displayed object by setting the object's
> type and the parameters associated to this kind of object.
It isn't clear what the benefits of a language-independent approach would
be. Implementing the visitor pattern is fairly easy and can be done in
each of these languages relatively easily, right? And the resulting code
would not depend on Microsoft technologies.
Reply ---------------------------------------------------------
You are right, the visitor pattern could be done in each of these
languages.
However, if that is done for you, it means less work isn't it ;-) And I
don't see the relationship between Microsoft dependencies and a schema like
suggested ?? If I where a DOJ lawyer probably, but we are not lawyers,
don't
we?
Conclusion:
I just tried to understand where the problem is. And from my understanding
it seems that maybe the problem is in the second part of XSL statements not
the first part. I mean not the pattern match part that everybody find quite
useful (you don't have to implement it yourself) but the action part that
people involved in _real_ web projects seems to find limitative. Maybe,
what
we have to read from all the comments people are making on this is that the
language suffer from procedural limitations (i.e. the action part or the
procedural part - the part that tells what to do when such a pattern is
encountered)
A different point of view worth a thousand point of IQ.
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com

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






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