[Home]  [List]  [News]  [Docs]  [FAQ]  [Downloads]  [Resources]  [About]
Search :
/Home /List

list4xt : Mailing list for the XT users community.

[list4xt] Re: Extensions to XT

Subject: [list4xt] Re: Extensions to XT

User: Website

From: Khun Yee Fung (KFung@extend.com)
Date: 20/06/2000 - 19:59


<quote>
This is looking interesting, but I am not sure to fully understand ;=)
...

Do you mean it would be used as an alternative to XPath to qualify node
sets ?
</quote>

Well, even more background then.

I always liked literate programming. And I used CWEB by Knuth for a while,
including for all the programs for my theses. But I stopped using it when I
started working in the industry. JavaDoc made me think about literate
programming again. But I could not find a satisfying literate programming
tool. CWEB and its derivatives (funnelweb, spiderweb, etc.) all have the
same fatal mistake: they are useful if you already know how you are going to
design and implement your application.

So I set out to write my own tool, hoping that I could use a more generic
tool than XSLT that I would be designing at the same time. I was thinking of
writing a GUI tool with the generic transformation language as the back end
of the tool.

There are two major components in a literate programming tool: the
pretty-printing of the documentation, and the assembly of the code in the
document. I wanted to do both well.

To make the story short, I did not want to force the programmer to do
something like:

<java-code>
  <statment><keyword>if</keyword><condition>(<expr>index <
2</expr>)</condition></statement>
</java-code>

Although this allows nice formatting of the code segment, it is simply out
of the question once the programmer has to maintain the code. There is no
way the programmer can even read the code.

Instead, I want the programmer to simply have something like:
<java-code>
  if (index < 2)
</java-code>

And as you can see, this is not syntactically correct Java code. The
simplest way to handle this situation is to simply say something like: `all
code segments will be formatted in Courier font' and copt out. But I don't
like reading courier code listings. If I had to read something like that, I
might as well read it off my screen.

Anyhow, to ensure the tool can format the code properly, I want the
programmer to have the ability to tell the formatter the syntax of a code
segment. Hence the ability to specify any context-free grammar. As the
parse-tree is returned, the formatting can be applied to the parse-tree.
Thus solving the pretty-printing portion of the literate programming tool.

The combination of the code segments is not as difficult as the formatting
part. But it poses other very interesting problems as well: pattern matching
and transformations. I was thinking of solving that part of the puzzle by a
more intuitive and generic transformation language. Of course, I stopped
that effort.

Replacing XPath? I have some ideas on that. But it will be part of the
generic transformation language. This context-free parsing part is just a
very small part of the whole system: handling only the text nodes and
attribute values.

Another use of the extension is to allow you to transform not only an XML
document, but also an XSLT document, including the XPath expressions in the
XSLT document, if you care to define the XPath syntax. And you can also
define meta-XSLT documents that include parameters not only on the element
level, but on the XPath expression level also.

One example to recognize a small arithmetic grammar:
 <grammar name="arithemtic">
  <terminals>
   <terminal name="a">a</terminal>
   <terminal name="plus">\+</terminal>
   <terminal name="times">\*</terminal>
  </terminals>
  <productions start="E">
   <E>
    <rule>
      <T />
    </rule>
    <rule>
      <E /><plus /> <T />
    </rule>
   </E>
   <T>
    <rule>
     <P />
    </rule>
    <rule>
     <T /> <times /> <P />
    </rule>
   </T>
   <P>
    <rule>
     <a />
    </rule>
   </P>
  </productions>
 </grammar>

The language to specfy the terminals is regular expression. So regular
expressions will come for free with the extension too. (Sorry about the lack
of namespaces, etc. The example is not meant to be XSLT compliant.)

Anyhow, enough about the extension. Any pointers to write extensions for XT?
Where should I look first? Advices?

Khun Yee

--
Mailing list for the XT users community.     (http://genyfinancejourney.com)
(mailto:list4xt-request@4xt.org?Subject=unsubscribe to unsubscribe)



Archive générée par hypermail 2b28 le 06/11/2001 - 11:46 CET

webmaster@4xt.org