According to this article
(http://xmlp.sourceforge.net/2002/extreme/index.html) there should be
xmLP version 1.1, but I found everywhere only the version 1.0
available for download.

Some constructs described in the article, such as multiply definion of
one section, do not work in my programs. Because of inconsistency of
documentation and implementation I am not sure, where mistake is - if
in my programme or if version 1.0 does not support this feature yet.

Hi,

SV_RFID (http://groups.yahoo.com/group/sv_rfid/)
is a Yahoo group that aims to gather together those
who have common interest in RFID, not only as just
a technology but also as a huge business
opportunity.

A quote from Forrester Research says,


"This technology (RFID) could radically change
the relationship between the customer and the
product. Fast forward 10 years, and it could
change the paradigm of what retailing is all
about." 

For a quick tour of how this technology
may affect your life please go to,

http://www.autoidcenter.org/aboutthetech_idiotsguide.asp

SV_RFID hopes to provide an environment where
members can communicate and share their passions,
visions, thoughts, concerns about RFID technology
as well as its business opportunities.

More specifically from technology perspective we
encourage discussions regarding tags, readers,
software infrastructure, database, datamining etc.
From  business applications perspective we may
cover topics in SCM, ERP, EAI, middleware,
logistics, retail, manufacturing, homeland
security, medical devices, airlines, automotive,
government, etc. We would also like to discuss
issues regarding privacy, security and standards.

Our members include executives, professors, VCs,
engineers, lawyers, business analysts, university
students, etc.

We cordially invite you to join us!

SV_RFID Group Moderator

-----Original Message-----
From: Charlie McDowell [mailto:charlie@...]
Sent: Wednesday, November 27, 2002 22:19
To: xml-litprog-l@yahoogroups.com
Subject: RE: [xml-litprog-l] Leo, Elucidator etc.

From the paper that sounds like a very nice system. How can I get a copy of the tool?
Was the paper ever published? If so where?

At 09:37 AM 11/27/2002 +0100, you wrote:

I have been lurking in this group for a while. I have used a kind of "lit prog" technique described in this paper.
 

Charlie McDowell, Professor                     (831) 459-4772 (w)
Computer Science Department                     (831) 427-2076 (h)
University of California                        (831) 459-4829 (fax)
School of Engineering               http://www.cse.ucsc.edu/~charlie
1156 High Street
Santa Cruz, CA 95064-1077


====
Unsubscribe: xml-litprog-l-unsubscribe@yahoogroups.com
Post message: xml-litprog-l@yahoogroups.com
http://groups.yahoo.com/group/xml-litprog-l/

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Is anyone here familiar with

   http://www.logilab.org/xmldiff/

Overview

XMLdiff is a python tool that figures out the differences between two
similar XML files, in the same way the diff utility does it for text
files. It was developed for the NARVAL project and should also be used
as a library. It can work either with XML files or DOM trees

----------

I recall a short discussion here about complications in using CVS
and diff with Leo files because of the XML encoding. I was wondering
if XMLdiff might be useful - especially in the context of the newer
version control systems based on WebDAV which apparently allow one
to use their own diff mechanism. See for example

   http://www.webdav.org/

and

   http://subversion.tigris.org/

Regards,
Bill Page.

** Reply to message from Charlie McDowell <charlie@...> on Sun, 01 Dec
2002 15:15:34 -0800

> My very rough prototype in fact does allow that - and indeed it was one of
> the trickiest (and most
> interesting) aspects of the development.
> An important question I want to address in a formal study is to determine
> if such editing is advisable or
> will it turn out to be more likely to introduce errors.

At a minimum, I think you would need a feature that automatically displays all
source & documentation points that are affected as you edit a particular point
in a tangled source.  That at least gives the programmer a sporting chance of
knowing what the real impact is of editing a particular tangled source.

> One colleague is even nervous about editing of tangled code at all given
> that you are now editing out of the context
> of the surrounding documentation. I of course think it can work with proper
> warning/support from the tool.

Even if you don't allow editing of the tangled sources, highlighting the text
that comes from the macro currently being edited in the tangled sources, along
with the current edit point, would make it far less necessary to need to edit
the tangled sources directly.  This would be especially so if you had a feature
that let you click on a character in a tangled source and jump to the macro
which that character came from.

	 Cheers,
		 Tony.

PS  This still leaves the question of how to get debuggers to trace errors back
to the literate line number, rather than the tangled source line number.
However, if you can click on a character in a tangled source to see which macro
it comes from, then only having debuggers giving you source lines numbers is
probably not such a problem.
====
Anthony B. Coates, Information & Software Architect
mailto:abcoates@...
MDDL Editor (Market Data Definition Language)
http://www.mddl.org/

My very rough prototype in fact does allow that - and indeed it was one of
the trickiest (and most
interesting) aspects of the development.
An important question I want to address in a formal study is to determine
if such editing is advisable or
will it turn out to be more likely to introduce errors.
One option would be to disallow multiple invocations. In fact I'd really
like to get an idea of how important
multiple invocation is in current LP usage. I also wonder how this relates
to aspect oriented programming.
Another option is to disallow editing of tangled code in sections that are
multiply invoked.
One colleague is even nervous about editing of tangled code at all given
that you are now editing out of the context
of the surrounding documentation. I of course think it can work with proper
warning/support from the tool.

At 10:57 PM 12/1/2002 +0000, you wrote:
>If you edit the content of such a macro via the
>tangled sources, it will have to cause multiple simultaneous changes in the
>tangled files.  Not impossible to do, but probably not trivial either.

Charlie McDowell, Professor                     (831) 459-4772 (w)
Computer Science Department                     (831) 427-2076 (h)
University of California                        (831) 459-4829 (fax)
School of Engineering               http://www.cse.ucsc.edu/~charlie
1156 High Street
Santa Cruz, CA 95064-1077

** Reply to message from Charlie McDowell <charlie@...> on Sun, 01 Dec
2002 14:54:05 -0800

> I should be able to allow the programmer to edit the tangled version as
> well. They can in fact do this
> now by manually unfolding all of the macro invocations - it just isn't in a
> separate window.
> There may be some scaling/performance problems here eventually, but I'm
> trying not to let such
> things get in my way now. New chips will solve that problem right?

As you have probably already realised, one thing to watch is where a macro is
invoked in multiple places.  If you edit the content of such a macro via the
tangled sources, it will have to cause multiple simultaneous changes in the
tangled files.  Not impossible to do, but probably not trivial either.  If you
ever allow parameterised macros (as FunnelWeb does), that will also make direct
editing of the tangled code trickier.

	 Cheers,
		 Tony.
====
Anthony B. Coates, Information & Software Architect
mailto:abcoates@...
MDDL Editor (Market Data Definition Language)
http://www.mddl.org/

I think this should be easy to add to what I'm developing. It could also
solve a problem for me.
I wasn't sure how I was going to handle pretty printing of the code
fragments, but if I keep a
dynamically tangled view around then I can pull the pretty printed
formatting (i.e. keyword coloring)
from that version. I'll keep you posted.

I should be able to allow the programmer to edit the tangled version as
well. They can in fact do this
now by manually unfolding all of the macro invocations - it just isn't in a
separate window.
There may be some scaling/performance problems here eventually, but I'm
trying not to let such
things get in my way now. New chips will solve that problem right?

At 10:39 PM 12/1/2002 +0000, you wrote:
>The key addition I would also like to see is "live" tangling, so that as well
>as your documentation window, you could have several source windows open
>showing how the tangled sources will look.  As you edit the macros in the
>literate document, you would see live updating of the tangler output in the
>source windows, hopefully with the colour coding and incorrect syntax
>detection
>that mainstream programming IDEs now provide.  Live tangling would
>overcome the
>(very real) problem of programmers not being sure if they have assembled their
>macros correctly or not.

Charlie McDowell, Professor                     (831) 459-4772 (w)
Computer Science Department                     (831) 427-2076 (h)
University of California                        (831) 459-4829 (fax)
School of Engineering               http://www.cse.ucsc.edu/~charlie
1156 High Street
Santa Cruz, CA 95064-1077

** Reply to message from "Jobling C.P." <c.p.jobling@...> on Thu, 28
Nov 2002 13:53:59 -0000

> One of the papers cited in that paper is to a
> technique called "Reverse Literate Programming" proposed by Markus
> Knasmüller (http://www.ssw.uni-linz.ac.at/Research/Projects/RevLitProg/)
> which appears to have a lot in common with Charlie McDowell's proposal.

I don't think it is that close.  I wasn't previously aware of any formal
discussion of "reverse LP", but it has come to mind in the past when people
have asked whether it wouldn't be better to leave sources intact and instead
hyperlink external documentation to them.  My answer is that this sounds like a
good way to analyse a body of poorly documented code that you have been tasked
to understand, but I don't see it working well for documenting code as it is
being written.  It doesn't encourage you to write documentation as you code,
and you would need to continually check what the code coverage of the
documentation was.  Also, as you edited the sources, I wonder if the links to
the documentation wouldn't turn out to be fragile & easily broken.

As I understand Charlie's work, it simply changes the LP metaphor a bit.
Normally, where a macro is called within another macro, you just see a
reference to the macro being called.  The code which is inserted when tangling
is not inlined into the woven version of the macro (although this is a feature
request for a future version of xmLP).  Charlie's proposal takes an interactive
view, where the default is to display a link to the macro being called, but a
user can interactively choose to see what the inlined (tangled) code would look
like.  This is a very good idea.

My thoughts as to what an ideal XML LP IDE would be like revolve around what
good WYSIWYG XML editors do.  An editor like XMetaL can make most XML document
formats look like a word processor page (note that the next version of Word
also promises this, which could be very interesting indeed).  This means that
the documentation can be edited in a WYSIWYG fashion, making weaving
unnecessary unless you need an alternative output format for others to read.
The key addition I would also like to see is "live" tangling, so that as well
as your documentation window, you could have several source windows open
showing how the tangled sources will look.  As you edit the macros in the
literate document, you would see live updating of the tangler output in the
source windows, hopefully with the colour coding and incorrect syntax detection
that mainstream programming IDEs now provide.  Live tangling would overcome the
(very real) problem of programmers not being sure if they have assembled their
macros correctly or not.

Charlie's solution addresses the same problem, but does so by progressively
displaying tangled output in the middle of the documentation view, while my
thoughts have tended more towards having the tangled code in separate windows.
I think these are complementary approaches, and having both available would not
be a bad thing at all.

	 Cheers,
		 Tony.
====
Anthony B. Coates, Information & Software Architect
mailto:abcoates@...
MDDL Editor (Market Data Definition Language)
http://www.mddl.org/

You can hide (fold) large chunks of code/documentation so you get a better overview of the code and that you can click on a function call (with links to the definition in the same file or another file) and it unfolds in place so you get an better overview of what the function does in that context.

I have been lurking in this group for a while. I have used a kind of "lit prog" technique described in this paper.
 

I was wondering if there was enough interest to bring a group of 30-50
individuals interested in LP
together in a workshop. Is there some conference that it would make sense
to have it precede or
follow? Would it be best as a 1-2 day stand alone event?


Charlie McDowell, Professor                     (831) 459-4772 (w)
Computer Science Department                     (831) 427-2076 (h)
University of California                        (831) 459-4829 (fax)
School of Engineering               http://www.cse.ucsc.edu/~charlie
1156 High Street
Santa Cruz, CA 95064-1077

-----Original Message-----
From: Charlie McDowell [mailto:charlie@...]
Sent: 26 November 2002 21:08
To: xml-litprog-l@yahoogroups.com
Subject: [xml-litprog-l] Leo, Elucidator etc.

>I am familiar with both Leo and Elucidative Programming (although not the
>Elucidator project).
>They each drift a little bit further from my interpretation of Knuth's LP
>concept than I wanted to go.
>With Leo, the outline is nice (and in fact the tool I'm developing will
>include a Leo like outline view),
>but it just isn't  full on LP. I didn't sense that it had a user base that
>made it the right choice as a
>starting point.

I think you may be wrong about Leo's user base is quite large. It's
certainly a very active development project with several thousand messages
on the bulletin board.

>The outline view is actually a rather easy view to generate. The folded
>view as I'm conceiving
>it is quite different (and was/is the most intellectually
>challenging/interesting part of what I'm doing).

I think that the outline is more of a model than a view in Leo. You are
actually creating nodes on a tree when you use Leo. Each node consists of
documentation, or code, or documentation and code. The node headings are
equivalent to Knuth's macros. The tree view does strain Knuth's original
concept a little as I think he was describing a directed graph rather than a
tree: features that I'd like to see in Leo, like hyperlinks from use to
definition, or in-line expansion are missing a la a folding editor. But as
an interactive tool for doing LP it's the best I've seen. As I said before,
the tangling (and untangling) facility is pretty much faultless!

>Likewise, Elucidative programming separates the code view and the
>documentation view, but links them together so
>you can easily move back and forth. To me this is again a big move away
>from Knuth's concept where the code
>and documentation are intertwined.

You are correct, but I could see no real reason why the tools supporting
elucidation needed to make this separation apart from a need to have
repetition with more or less detail.

>I'm very much concerned about creating just "yet another" LP tool. I'm
>trying to make sure I learn from what others
>have done, but I didn't see either of these as having important ingredients
>that I wanted to build on (but I could easily
>be wrong).

>The folding idea I am implementing it not new, even in the LP literature
>(although I wasn't aware of this comment
>when I conceived off the idea). It was proposed in 1986. Thimbleby observed
>(Thimbleby, H., Experiences of literate programming using cweb (a variant
>of Knuth's WEB). Computer Journal, 1986. 29(3): p. 201-11)
>that one "of the disadvantages of literate programming ... is that the
>programmer cannot view the code of macro bodies in situ at the point of
>invocation." He goes on to propose "an interactive version" in which the
>programmer "would press a button and an invocation would unfold into a
>(name, body) window in position."

I liked this feature of your mini example. I've used folding editors myself
and have seen other proposals for an LP-like tool that use folding as a key
feature.

>I completely agree that it would be great to agree on a DTD. I'd be quite
>happy to adopt anything reasonable.
>That is a simple minor change to the input parsing and save operations.

Can I suggest that you start from xmLP 1.0! It works well provided that you
don't mind using XHTML in your documentation "chunks".


>Charlie McDowell, Professor                     (831) 459-4772 (w)
>Computer Science Department                     (831) 427-2076 (h)
>University of California                        (831) 459-4829 (fax)
>School of Engineering               http://www.cse.ucsc.edu/~charlie
>1156 High Street
>Santa Cruz, CA 95064-1077


Yahoo! Groups Sponsor
ADVERTISEMENT




====
Unsubscribe: xml-litprog-l-unsubscribe@yahoogroups.com
Post message: xml-litprog-l@yahoogroups.com
http://groups.yahoo.com/group/xml-litprog-l/

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
[Chris J.]


Dr Chris P. Jobling [C.P.Jobling@...]
School of Engineering
University of Wales Swansea, Singleton park, Swansea SA2 8PP, UK.
Tel: +44 1792 295580; Fax: +44 1792 295676
WWW: www.engineering.swan.ac.uk

 

 -----Original Message-----
From: Charlie McDowell [mailto:charlie@...]
Sent: Tuesday, November 26, 2002 22:08
To: xml-litprog-l@yahoogroups.com
Subject: [xml-litprog-l] Leo, Elucidator etc.

I am familiar with both Leo and Elucidative Programming (although not the Elucidator project).
They each drift a little bit further from my interpretation of Knuth's LP concept than I wanted to go.
With Leo, the outline is nice (and in fact the tool I'm developing will include a Leo like outline view),
but it just isn't  full on LP. I didn't sense that it had a user base that made it the right choice as a
starting point. The outline view is actually a rather easy view to generate. The folded view as I'm conceiving
it is quite different (and was/is the most intellectually challenging/interesting part of what I'm doing).
Likewise, Elucidative programming separates the code view and the documentation view, but links them together so
you can easily move back and forth. To me this is again a big move away from Knuth's concept where the code
and documentation are intertwined.

I'm very much concerned about creating just "yet another" LP tool. I'm trying to make sure I learn from what others
have done, but I didn't see either of these as having important ingredients that I wanted to build on (but I could easily
be wrong).

The folding idea I am implementing it not new, even in the LP literature (although I wasn't aware of this comment
when I conceived off the idea). It was proposed in 1986. Thimbleby observed
(Thimbleby, H., Experiences of literate programming using cweb (a variant of Knuth's WEB). Computer Journal, 1986. 29(3): p. 201-11)
that one "of the disadvantages of literate programming ... is that the programmer cannot view the code of macro bodies in situ at the point of invocation." He goes on to propose "an interactive version" in which the programmer "would press a button and an invocation would unfold into a (name, body) window in position."

I completely agree that it would be great to agree on a DTD. I'd be quite happy to adopt anything reasonable.
That is a simple minor change to the input parsing and save operations.

Charlie McDowell, Professor                     (831) 459-4772 (w)
Computer Science Department                     (831) 427-2076 (h)
University of California                        (831) 459-4829 (fax)
School of Engineering               http://www.cse.ucsc.edu/~charlie
1156 High Street
Santa Cruz, CA 95064-1077


====
Unsubscribe: xml-litprog-l-unsubscribe@yahoogroups.com
Post message: xml-litprog-l@yahoogroups.com
http://groups.yahoo.com/group/xml-litprog-l/

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

On Tue 2002-11-26 (10:31), Jobling C.P. wrote:
> As a university teacher who wants to use LP as a format for describing Java
> programs to students, the need for a browsable/printable format which can
> use rich text in the documentation chunks is not so easily dismissed.
       ~~~~~~~~~

I make notice of the downcase spelling here :-) For me as a user it would
be enough if every documentation part could be entered in Wiki style
and transformed when the whole thing is parsed. I know too little about
Wiki implementations but there is a quite solid one based on Python
http://moin.sourceforge.net/. Maybe the documentation chunks can be
piped through a Wiki->HTML/XML translator which must be somewhere within
the code?

> Maybe this community could make the
> most progress by agreeing on a common DTD for the LP itself, lobbying for
> rich-text in Leo's documentation nodes?
>

I don't know how to extract the doc nodes with an XSLT tool at all, as
they defy XML grammar!

> It's great that this mailing list has finally woken from its long slumber!

Indeed.

Greetings


Johannes

>

Charlie

Can I also point you in the direction of Leo
(http://personalpages.tds.net/~edream/front.html). It does pretty much what
your LP++ minisample does but with "live", editable code. Leo uses an
outliner metaphor rather than a folding editor metaphor, but that's just a
view (right?). The only missing feature is support for rich text in the
"documentation nodes" to enable a weave feature. Ed Ream, Leo's developer
sees this as an advantage: as you can manipulate the literate programme
directly in Leo, there is no need for a read-only format. Indeed, because
the Leo file format is XML, you can use XSLT/FO to generate HTML or
printable LPs (as has been done, at least as a prototype by Joe Orr (see
http://www.jserv.com/jk_orr/xml/leo.htm). It has to be said that tangling
works almost flawlessly, and you'd have to put a lot of work into a tool
that does this as well and intuitively as Leo.

As a university teacher who wants to use LP as a format for describing Java
programs to students, the need for a browsable/printable format which can
use rich text in the documentation chunks is not so easily dismissed. I
often need to include pictures and styles like bulleted lists, etc, in my
expositions. Furthermore, I would be nervous of exposing novice programmers
to a tool like Leo on top of a Java IDE (albeit a  simple one, I use BlueJ
http://www.bluej.org) and everything else they need to learn. So a web
browser view with expandable hyperlinks or a word document for printing and
off-line study would be very attractive. Maybe this community could make the
most progress by agreeing on a common DTD for the LP itself, lobbying for
rich-text in Leo's documentation nodes?

It's great that this mailing list has finally woken from its long slumber!

Chris

P.s Another tool that is worth looking at is the Java Elucidator
(http://elucidator.sourceforge.net/) being developed by Thomas Vestdam and
others at Aalborg University in Denmark. The framework is complex, but the
output is much like your proposal for LP++.

p.p.s  As a staring point for a Leo extension, another open-source python
project called docutils (http://docutils.sourceforge.net/) has a deliverable
called reStructuredText which allows simple markup, such as might be used in
plain-text email, to be converted into nicely formatted text.
reStructuredText is intended as a pragmatic format for documenting Python
doc comments (equivalent to JavaDoc) in a form that can be processed to
produce nice printable API or user documentation. The markup is simple and
unintrusive enough to plug straight into Leo, and, because the processors
are written in Python, they potentially fit right in as a plug-in.

p.p.p.s I have cross posted this to Ed Ream and Thomas Vestdam to widen the
discussion.


Dr Chris P. Jobling [C.P.Jobling@...]
School of Engineering
University of Wales Swansea, Singleton park, Swansea SA2 8PP, UK.
Tel: +44 1792 295580; Fax: +44 1792 295676
WWW: www.engineering.swan.ac.uk

-----Original Message-----
From: Charlie McDowell [mailto:charlie@...]
Sent: 25 November 2002 20:26
To: xml-litprog-l@yahoogroups.com
Subject: [xml-litprog-l] WYSIWYG LP

I absolutely agree. I'm currently working on a WYSIWYG literate programming
and the underlying
storage model of the program is XML (inspired by your xmLP work).
You can read a bit about what I'm doing here:
http://www.soe.ucsc.edu/~charlie/projects/litprog/

At 09:27 PM 11/24/2002 +0000, you wrote:
>I wish I had as nice a front end for
>xmLP.  I've often felt that the lack of nice front-ends has hurt the
>take-up of
>LitProg (& Emacs does not count as a nice front-end, not for the 95%
>majority).
>An ideal LitProg editor would be WYSIWYG, so that what you see when editing
is
>equivalent to what you would get with a traditional LitProg tool after
>"weaving" the documentation.

Charlie McDowell, Professor                     (831) 459-4772 (w)
Computer Science Department                     (831) 427-2076 (h)
University of California                        (831) 459-4829 (fax)
School of Engineering               http://www.cse.ucsc.edu/~charlie
1156 High Street
Santa Cruz, CA 95064-1077



Yahoo! Groups Sponsor
ADVERTISEMENT




====
Unsubscribe: xml-litprog-l-unsubscribe@yahoogroups.com
Post message: xml-litprog-l@yahoogroups.com
http://groups.yahoo.com/group/xml-litprog-l/

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

I absolutely agree. I'm currently working on a WYSIWYG literate programming
and the underlying
storage model of the program is XML (inspired by your xmLP work).
You can read a bit about what I'm doing here:
http://www.soe.ucsc.edu/~charlie/projects/litprog/

At 09:27 PM 11/24/2002 +0000, you wrote:
>I wish I had as nice a front end for
>xmLP.  I've often felt that the lack of nice front-ends has hurt the
>take-up of
>LitProg (& Emacs does not count as a nice front-end, not for the 95%
>majority).
>An ideal LitProg editor would be WYSIWYG, so that what you see when editing is
>equivalent to what you would get with a traditional LitProg tool after
>"weaving" the documentation.

Charlie McDowell, Professor                     (831) 459-4772 (w)
Computer Science Department                     (831) 427-2076 (h)
University of California                        (831) 459-4829 (fax)
School of Engineering               http://www.cse.ucsc.edu/~charlie
1156 High Street
Santa Cruz, CA 95064-1077

Hello all,

Well, I guess I can retire back to life on the farm
with a clear conscience - seems like it's all been
done!

Seriously, I had no idea that the "state of the art"
had reached this level. I feel like I have just
discovered gold in a most un-expected place - in the
"waste land" called by it's inhabitants "OpenSource".
Waste land, indeed! Not. I guess I have been toiling in
the realm of paid consulting work for too long. Having
just read Dijkstra's "Humble Programmer" article again
after what seems like a whole generation has passed,
I am in a philosophical mood.

So it seems to me that open source (abd GNU etc. etc.)
is what happened *after* the software crisis that
Dijkstra talked about. When the original situation of
expensive hardware plus a little software reversed
dramatically, and the ratio of the cost (and effort)
of software development to the cost of the hardware
went "through the roof", it seems that a large part
of the programming profession went underground. Not
that one should think that the software crisis is over,
far from it, but some amazing and revolutionary ideas
do seem to be re-surfacing...

I have just finished looking at TeXmacs, Leo, Python
and xmLP

   http://www.texmacs.org/
   http://personalpages.tds.net/~edream/front.html
   http://www.python.org/
   http://xmlp.sourceforge.net/

and frankly I am amazed. But of course food tastes
wonderful to someone who is starving. These are exactly
the kind of tools that I was hoping would be available
for a new integrated development/authoring system for
the open source version of Axiom and for mathematical
programming in general. Sure a greated degree of
integration would be nice. But these are open source
tools so (in principle) all that is needed is effort.
Right?

I am especially encouraged by the use of XML and XSLT.
Standards are what made the Web and for that matter the
Internet itself, possible. Yes, standards *are* made to
be broken, but the fantastic (and largely unexpected)
success of the Internet should have taught us something:
It is possible to overcome the Babel (cf. Neal Stephenson,
"Snow Crash"). Mathematical software in the form of Maple,
Mathematica, Maxima, MuPad, Reduce, Axiom/Aldor (and many
many more) is in such a state of Babel - too many languages
and too many conflicting concepts. Of course variety is
necessary in the intellectual ecosystem, but too much
is almost as bad as too little.

I am very much in favor of attempting to apply accepted
standards (where they exist) in projects such as Axiom.
In that regard, let me ask a question:

LaTex is a defacto standard notation for mathematical
markup but MATH/ML is rapidly evolving as a more
"modern" alternative. Should one attempt to adopt such
a radially different (and some say exceedingly verbose)
approach as MATH/ML in the design of a new user
interface for Axiom? How advanced are the graphical
rendering packages? (More open source?) Could MATH/ML
be integrated with a tool like Leo? The alternative
of a LaTex-like interface is already available in
TeXmacs. But the use of XML as a standard visible
"internal" representation format strikes me as very
very desirable. And of course by design MATH/ML is
much more compatible with XML than is LaTex encoding.

How to choose?

Regards,
Bill Page.

http://savannah.nongnu.org/projects/axiom


> -----Original Message-----
> From: Johannes Hüsing [mailto:tmi0m0@...]
> Sent: Monday, November 25, 2002 8:58 AM
> To: xml-litprog-l@yahoogroups.com; Bill Page; 'Joris van der Hoeven'
> Cc: texmacs-dev@...; axiom-developer@...; 'Norman
> Ramsey'; 'Barry Trager'; 'Manuel Bronstein'; 'William Sit'
> Subject: Re: [xml-litprog-l] Re: noweb, pamphlets, and TeXmacs
>
>
> On Sun 2002-11-24 (21:27), Anthony B. Coates wrote:
> > ** Reply to message from "Bill Page"
> <bill.page1@...> on Sun,
> > 24 Nov 2002 15:00:24 -0500
> >
> > A couple of things.  TeXmacs looks nice.  I wish I had as
> nice a front
> > end for xmLP.  I've often felt that the lack of nice front-ends has
> > hurt the take-up of LitProg (& Emacs does not count as a nice
> > front-end, not for the 95% majority). An ideal LitProg
> editor would be
> > WYSIWYG, so that what you see when editing is equivalent to
> what you
> > would get with a traditional LitProg tool after "weaving" the
> > documentation.
>
> I don't know if I still need to draw your attention to LEO
> (http://sourceforge.net/projects/leo). The DTD of Leo output
> files is naturally not 1:1 with xmLP, but things like
> lp:usage attributes can be generated automatically.
>
> Of course, everyone has their own idea of what LP has to look
> like, but after using Leo for a couple of weeks my impression
> is that of a
> very flexible tool that can be geared towards many
> structures, including at least an important subset of the
> xmLP grammar.
>
> Greetings
>
>
> Johannes
> >
>

Hi

>How difficult would it be to write an XSLT style
>sheet that would perform weave and tangle on an
>XML file? I almost sat down to give it an initial
>try when I thought about doing a web search on the
>subject of "XML"

I never published it, but part of my (1999-2000) Master's work was XML LP
with XSL tangle/weave. In fact, it was self-hosting: the XSL programs
themselves were literate. One goal was to make the LP markup compatible with
DocBook, so I would get maximum markup semantics with minimum new markup. I
used only HTML as an output format. That was an implementation choice, not
an archtectural foundation.

I also bolted on markup for requirements tracing. That way, the statement of
the problem, the solution, verification scripts and data, etc, would all be
literate and would also be strung together in a way compatible with good
software engineering practice. (HTML output format was especially nice,
since I could link requirements to implementation etc.) The requirements
tracing markup and LP markup were independent of each other. They could be
used separately or together.

-- Tom VanCourt

PS: The biggest reason I never published was that practice in the field was
already way ahead of my work. The novelty I added was standards compliance
for text markup (DocBook) and software engineering documentation (per IEEE
standards).

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail

On Sun 2002-11-24 (21:27), Anthony B. Coates wrote:
> ** Reply to message from "Bill Page" <bill.page1@...> on Sun, 24 Nov
> 2002 15:00:24 -0500
>
> A couple of things.  TeXmacs looks nice.  I wish I had as nice a front end for
> xmLP.  I've often felt that the lack of nice front-ends has hurt the take-up
of
> LitProg (& Emacs does not count as a nice front-end, not for the 95%
majority).
> An ideal LitProg editor would be WYSIWYG, so that what you see when editing is
> equivalent to what you would get with a traditional LitProg tool after
> "weaving" the documentation.

I don't know if I still need to draw your attention to LEO
(http://sourceforge.net/projects/leo). The DTD of Leo output files is
naturally not 1:1 with xmLP, but things like lp:usage attributes can
be generated automatically.

Of course, everyone has their own idea of what LP has to look like,
but after using Leo for a couple of weeks my impression is that of a
very flexible tool that can be geared towards many structures, including
at least an important subset of the xmLP grammar.

Greetings


Johannes
>

** Reply to message from "Bill Page" <bill.page1@...> on Sun, 24 Nov
2002 15:00:24 -0500

A couple of things.  TeXmacs looks nice.  I wish I had as nice a front end for
xmLP.  I've often felt that the lack of nice front-ends has hurt the take-up of
LitProg (& Emacs does not count as a nice front-end, not for the 95% majority).
An ideal LitProg editor would be WYSIWYG, so that what you see when editing is
equivalent to what you would get with a traditional LitProg tool after
"weaving" the documentation.

Note that xmLP takes most of its ideas on literate programming from FunnelWeb
(http://www.ross.net/funnelweb/) which supports TeX, LaTeX, and HTML as
underlying document formats, as well as providing its own markup for simple
documents.  So, you could copy ideas from FunnelWeb to use in TeXmacs, if you
wanted.

> I agree completely with your point of view. It is
> essential to find some way to keep it simple the
> way Norman managed to do with WEB. I think the
> trouble with powerful (i.e. very flexible and
> expressive) languages like XML is that there is an
> urge to become less "humble" (in the sense of Edsger
> Dykstra).

XML markups for documents, e.g. DocBook, are no more complicated than LaTeX.
However, what one hopes to get from XML is composability & reusability.  Hence
xmLP defines a minimal set of tags, and a combination of DocBook + MathML +
xmLP would provide much the same functionality as I used when using FunnelWeb
for my physics studies, if had a suitable way to produce printed output (and
that would probably require PassiveTeX, so I still wouldn't be able to escape
TeX as an underlying technology).

	 Cheers,
		 Tony.
====
Anthony B. Coates, Information & Software Architect
mailto:abcoates@...
MDDL Editor (Market Data Definition Language)
http://www.mddl.org/

On Sunday, November 24, 2002 3:00 PM I wrote:

> [Bill Page]
> > I think that Anthony Coates (see links above) has
> > already done quite an excellent job of defining a
> > simple set of tags and attributes.
> ...
> Check out the quick sketch at
>
>   http://www.vivtek.com/lpml/language.html
>

I case I have carelessly given the wrong impression,
please note that the link above is to work by
Michael Roberts <michael@...> and appears
to be unrelated to Anthony Coates.  But in my
opinion, both of them seem to have the right idea.

> > and also the more formal definitions at
> >
>   http://xmlp.sourceforge.net/2002/extreme/index.html#fragment-dtd
>
> > I really think that two or three well-chosen tags
> > should cover everything that we want to do (w.r.t.
> > tangle and weave; folding and such is yet another
> > story). This is what we should discuss in my opinion.
>
> I agree completely with your point of view. It is
> essential to find some way to keep it simple the
> way Norman managed to do with WEB.

Regardless,
Bill Page.

On Sunday, November 24, 2002 2:22 PM Joris
van der Hoeven TeXmacs@... wrote:
>
> [Bill Page]
> > I think that Anthony Coates (see links above) has
> > already done quite an excellent job of defining a
> > simple set of tags and attributes. These could
> > probably be used almost directly as a model for
> > TeXmacs.
>
> Thanks for the pointers. Unfortunately, I could not
> find a detailed summary of the relevant *tags* being
> used.
>

Check out the quick sketch at

   http://www.vivtek.com/lpml/language.html

and also the more formal definitions at

   http://xmlp.sourceforge.net/2002/extreme/index.html#fragment-dtd

> I really think that two or three well-chosen tags
> should cover everything that we want to do (w.r.t.
> tangle and weave; folding and such is yet another
> story). This is what we should discuss in my opinion.

I agree completely with your point of view. It is
essential to find some way to keep it simple the
way Norman managed to do with WEB. I think the
trouble with powerful (i.e. very flexible and
expressive) languages like XML is that there is an
urge to become less "humble" (in the sense of Edsger
Dykstra).

@unpublished{EWD:EWD340,
    author = "Edsger W. Dijkstra",
    title = "The humble programmer",
    year = "1972",
    note = "Turing Award lecture; published as {\cite EWD:EWD340pub}",
    url = "http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD340.PDF",
    fileSize = 473 KB
    }

See also

   http://www.cs.utexas.edu/users/EWD/

I hope that his work will continue to inspire
et another generation of programmers.

   http://www.cs.utexas.edu/users/EWD/obituary.html

Regards,
Bill Page.

Everyone,

I am glad to see that this is such a "hot topic"!

BTW, I am sorry that some of you (like me) who are
members of multiple lists are likely receive
several copies of this message. It seems sort of
unavoidable for the moment while we are exploring
just how "interdisciplinary" this subject is. Perhaps
some we should absorb this subject back into the Axiom
mailing list since that is where is started. Those
people who are interested will have had a chance
to subscribe if they want to monitor this subject.

Anyway, I spent some time today thinking about alternate
mark-up languages for pamphlets. I suppose what I do
for a living could not help but intrude on my views
in this project... depressing perhaps, considering
that I would like to view this as an ambitious hobby
rather than "work" ... <frown>

Anyway, I do a lot of work with XML and XSL style sheets
these in the context of large scientific bibliographic
databases. Also, I have been reading about some ideas
expressed on the TeXmacs list about XML. A quick look
at the TeXmacs file format shows many very obvious
relationships to XML. In fact it seems that it could
almost be 1-1 except for a slightly different tag
syntax. There is an awful lot of work being done
these days on XML as the prime candidate "next
generation" structured document language. And it
turns out that "structured documents" have many
many uses. They are a kind of half-way point between
data bases record and free form text documents.

XSL (or more properly XSLT) is a structured document
transformation language that is itself in XML format.
The main purpose of XSLT these days is to generate
HTML to be displayed in a web browser. The Microsoft
browser and several others even include the XSLT
processor in the browser itself. And implementations
of XSLT processors exist for almost all server
environments. Besides HTML, other output formats are
possible, e.g. PDF format etc.

So the concept was this (expressed as a question):
How difficult would it be to write an XSLT style
sheet that would perform weave and tangle on an
XML file? I almost sat down to give it an initial
try when I thought about doing a web search on the
subject of "XML"

   http://xmlp.sourceforge.net/

and

   http://groups.yahoo.com/group/xml-litprog-l/

see also

   http://www.vivtek.com/litprog.html

Damn the web! It seems that someone somewhere has
always already thought of all the good ideas ...
<grin>.

> From: Joris van der Hoeven [mailto:TeXmacs@...]
> Sent: Sunday, November 24, 2002 12:17 PM
> ..
> Notice that TeXmacs is not just capable to properly
> format a large subset of TeX/LaTeX, but that it also
> provides mark-up which is not available in TeX/LaTeX
> (hyperlinks, actions, simple folding, etc.). What
> is more, like in TeX/LaTeX, you may define your own
> mark-up, and, like in Emacs, construct special editing
> modes for editing such mark-up. This may apply in
> particular to things like customized ways of folding,
> direct execution of an Axiom example from the
> documentation, etc.
>
> > 0) The ability to recognize and format a code chunk.
> > 1) The ability to recognize the <<defn>>=,
> > concatenation, and <<use>> features of the code
> > chunks.
>
> ...
> However, as I pointed out before, it might be better
> to directly use the TeXmacs format with additional
> tags and write the operations like tangle and weave
> in Scheme.
>
> ... as I said before, there is no reason to distinguish
> between tangle and weave and no reason to limit oneself
> to two operations.
>
> > 4) Bill has suggested that the folding mechanism
> > know about the code chunks and be able to fold and
> > unfold them. Perhaps the way to make the "untangle"
> > work would be to ignore the separate buffer idea
> > above and just use folding. I have no opinion about
> > either path yet.
>
> In a dynamic editor like TeXmacs, it should be noticed
> that folding/unfolding becomes in fact a quite subtle
> operation. In fact, one has to think about the kind of
> semantics that one requires.
>
> For instance, do you see folding as an operations
> which makes a change in the text, or rather like
> an operation which modifies the view of a text?
> The first interpretation is easiest to implement.
> In the second case, one has to define the notion
> of a "view" (and in particular: what information
> determines a view?). Also, you would have to
> think about how to undo changes.
>

I really like the idea that the code appears "folded"
into the document, but still part of it. When the folds
are collapsed, the result is just documentation. But
when the folds are expanded, they are visible and
editable just like any other part of the document. So
in that sense I am only talking about a "view" of
the document (with one, several, or all folds collapsed).

I would definitely say that folding should not be
an operation that changes the text, however we it
might be desirable if it (optionally?) affected how
the documented was printed as well as displayed.

This sort of folding is now a common feature of
math packages like Maple and Mathematica. It helps
a lot to be able to read a document in a "top down"
fashion. In this sense the programming code is at
the "bottom" of the document fold structure.

> Another difficulty has to do with TeXmacs' ability
> to let the user define his/her own macros. What
> should be the semantics
> of a macro which is built upon a "fold" tag?
>
> > 5) There are other ideas, not yet exposed, that
> > it would be nice to have supported. I guess I
> > need to talk more about the pamphlet idea in depth.
>
> Well, it would be nice to make up a list of all tags
> (with options and everything) which might be useful
> for pamphlet files. You might also want to take a
> look at some (still very rudimentary) ideas in the
> tmdoc format.
>

I think that Anthony Coates (see links above) has
already done quite an excellent job of defining a
simple set of tags and attributes. These could
probably be used almost directly as a model for
TeXmacs.

> At the moment, I mainly see the "chunk" tag as
> a variant of our "specific" tag, which is used in
> order to export content in a specific way to specific
> formats. We basically have to re-specify the semantics
> of such a tag in a very general setting.
>
> > First, you compose a set of Pamphlet files "across
> > the system" so that you could document, say, all of
> > the matrix facilities currently available.
> >
> > Second, you compose a set of Pamphlet files "thru
> > the system" so that you could document, say, the
> > integration mechanism from the top level function
> > all the way to the implementation details.
>
> My way of viewing this is the use of one file for
> each atomic functionality of the system. Each such
> file should come with meta-information like the bigger
> classes to which it belongs (linear algebra, topology,
> etc.). Each file may also contain information about
> other relevant related files or how to traverse files
> in a sensible order (cf. tmdoc style). One may then
> implement special functions into TeXmacs for extracting
> the information one needs.
>
> > Thus you can insert and extract Booklets with Axiom
> > making it easier to share knowledge.
> >
> ...
> > Huge dream, I realize, but except for the dishes,
> > I see no technical reason why it can't be done.
> >
> > This implies, of course, that Pamphlets can be
> > decomposed into a finer level of detail which is
> > still under development.
>
> Well, it all boils down to inventing suitable mark-up
> tags which reflect the complexity of the problem. So
> please give this matter a thought and come up with
> some more precise proposals. After that, we will have
> a discussion and see how to implement all this in
> TeXmacs.
>
> > Currently noweb needs to expand the chunk definition
> > syntax to handle some more general scheme such as a
> > URL. We need to be able to extract code chunks from
> > other pamphlets so that you can have the following
> > situation:
> >
> > pamphlet A:  (the definition document)
> >     ...
> >     <<foo>>=
> >     ...
> >
> > pamphlet B:  (the using document)
> >     ...
> >     <<pamphlet:/path/A#foo>>
> >     ...
> >
> > It would be useful if this could happen for text
> > blocks also so that generally useful descriptions
> > could be inserted into multiple pamphlets. Since
> > the text blocks currently have no label this becomes
> > problematic. We need to develop text labels so we
> > can follow a uniform scheme. Multiple text blocks
> > containing essentially the same information already
> > exist in the system. This needs to be fixed.
> >
> ...
> As I see it now, you have the following ingredients
> for chunk tags:
>
> 1) A "format" which determines the program which
> should be used in order to do extractions. More
> generally, it reflects the purpose of the enclosed
> content (documentation, code, example, etc.).
>
> 2) An "identifier" for specifying how several chunks
> should be grouped together. In fact, it might be
> nice to see this independently from the chunk tags,
> but rather as a variant of labels and references.
> In other words, logical grouping of different parts
> of content may be nice in other circumstances too.
>
> So maybe we should see the chunk tag as the
> combination of two more basic tags: one for
> specifying the purpose, functionality or class of
> a given region of text, and one for grouping
> scattered pieces of information.
>

I think you (Joris) may be surprised how close
your ideas are to Anthony's on this!

> > RE: TEXMACS CHANGES
> >
> > Currently TeXmacs could take the following
> > steps, probably as a joint effort, to support
> > Axiom:
> >
> > 1) Recognize noweb format
>
> And we should decide whether we want to keep on
> working with this format, or whether we want to
> switch to a format for which it will be easier
> to add new features.
>
> > 2) Integrate commands to notangle and noweave.
>
> This should be straightforward to write in Scheme
> once that one has the appropriate tags.
>
> > 3) Possibly either support
> >    a) folding out code
>
> Please think more precisely about the semantics
> that you would like to have.
>
> >    b) notangle, noweave to "dependent" buffers
>
> Cf. improving the mark-up for inclusions like in
> the tmdoc style.
>
> ...
> I also remind you that TeXmacs does not have a
> one-to-one mapping with TeX/LaTeX. In other words,
> you can not longer use TeX/LaTeX as a reliable
> format for explanatory text in this scheme. If you
> want to edit the original document using TeXmacs,
> it is better to either use TeXmacs as the document
> format for your pamphlet files, or at least to
> replace chunks of LaTeX by chunks of TeXmacs.
>

Regards,
Bill Page.

At 17:49 7-11-2002 -0000, j_montroos wrote:
>Hi people,
>
>I need some links to Xml tutorial that can show me how i can acces
>mySql database.

That does not exactly match the Subject line, "Xml tutorial for beginners"!
<g>

XML has nothing to do with SQL or databases of any kind. Try the first
three references in the Bookshelf at
http://www.byteryte.nl/html/xml_and_sgml.html, I think you'll find what you
need there.

HTH,
-Brigit van Loggem

Byte Ryte bv
http://www.byteryte.nl

Hi people,

I need some links to Xml tutorial that can show me how i can acces
mySql database.

thx a lot