--- In xpl-dev@y..., cagle@o... wrote:
Garreth,
About the relationship between XSLT and XPL --
XSLT can be a pretty ugly language, but it's powerful -- I have an
implementation of XPipes (my own XML based language) that actually
works as
a pre-processor to convert XPipes code to XSLT. Thus, I now have
structures
in my XPipes code like:
<script name="str" source="http://www.xpl.com/cagle/namespace.asp?
ns=str"/>
<script name="table"
source="http://www.xpl.com/cagle/namespace.asp?ns=table"/>
<param name="cell" value="255"/>
<function name="charTable" cell="$cell">
<table>
<for var="i" start="0" end="128" by="1" test="$cell div 16
< $i"
>
<row>
<for var="j" start="$i*16" end="$i*16+15" by="1">
<cell><eval>$j</eval></cell>
<cell><eval>str:char($j)</cell>
</for>
</row>
</for>
</table>
</function>
This particular function creates a table of &#NN; characters, giving
both
the number and symbol of the character, 16 symbols per row. The cell
parameter indicates how many cells should be created, and if exceeded
(when
divided by 16), causes the evaluation to stop. If you take out the
brackets,
this code becomes essentially the same as
include str;
function charTable($cell=255){
out('<table>');
for {$i=0;$i<=128 && cell/16<$i;$i++){
out('<row>');
for {$j=$i*16;$j<=$i*16+15;$j++){
out('<cell>',$j,'</cell>');
out('<cell>',str:char($j),'</cell>');
}
}
}
However, there are some sizeable differences here even so, the
biggest being
that the resulting entity here is a text object, while in the context
of
XSLT it would be a table object, etc.
The point about all of this is that XPipes is essentially a two pass
XSLT
entity -- the first pass converts the XPipes could (using XSLT) into
XSLT,
while the second actually applies the XSLT to a stub entity to handle
parameterization of information. Indeed, in a number of cases, the
XPath
elements are mapped one to one into their XSLT representation: <if>
becomes
<xsl:if>, etc.
The key to working with any XML based scripting language is to
recognize
that it must be XML based -- no additional notations beyond what
already
exists, a minimal (or non-existent) reliance on processing
instructions
(which are somewhat intractible solutions for transformations), no
semi-colon delimited code blocks, etc. One of the primary
requirements to me
of an XPL should be that it should be possible to generate an XPL
script
through the application of an XSLT script (or by extension, an XPL
script),
while at the same time it should be possible to take an XPL script and
similarly transform it into some other output (perhaps XML
documentation,
perhaps pretty printing, perhaps an interface query mechanism). In
other
words, XPL should be both in- and out- transformable.
-- Kurt Cagle
----- Original Message -----
From: "Garreth Galligan" <garreth.galligan@o...>
To: <xpl@e...>
Sent: Monday, June 19, 2000 8:45 AM
Subject: [XPL] Re: The structure of classes in XPL
> Richard Anthony Hein wrote:
>
> >XPL doesn't need classes, but to make people comfortable we
> >can make them using XPointer
>
> This is fascinating, but I'm afraid I'm not too up to speed with
> XPointer. Do you know of any good reference material? W3C
> documentation is a slow, tedious read.
>
> >Subject: [XPL] requirements
> >3. XPL must be human readable.
>
> Agree with you absolutely, otherwise there would be no point in
using
> a markup language for the job.
>
>
> Kurt Cagle wrote:
>
> >I think the idea of writing a general meta-language for
> >programming is ill-advised
>
> With you on this one; if I'm right about your meaning in 'general
> programming' as raised in some early posts which, more or less,
> envisage XPL as storage/transfer/interface/whatever medium for
> various existing languages. Great science, but a little too 'Star
> Trek' for me right now. However I'm still on the side of XPL as
> a 'meta-language' of sorts, for creating XPL based micro languages.
>
> >Let's concentrate on extending what already exists,
> >making XSLT more robust,
>
> Well with you in the spirit of the concept, which is to use
> applications of XPL for operation on other ML's. But it would take a
> lot of persuading to get me over my innate dislike of XSLT. It's
such
> an *ugly* language, and is rooted in my mind as a tool for
> publishingMLs most likely to be produced in a WYSIWYG application.
> One needs to take a very deep breath before trying to hand code the
> stuff. I'm inclined to think of XSLT as a round hole to XPL's square
> peg, but then my experience with XSLT is hardly extensive and I'm
> open to persuasion...
>
>
>
>
> To unsubscribe from this group, send an email to:
> xpl-unsubscribe@o...
>
>
>
>
--- End forwarded message ---
|
