I was running through the example .oml's in the zip archive on the o-xml.org web site. Got them running for the most part (debian/kaffe), but a few of them seem to have errors. One in particular, chapter-8.oml is not well formed XML. Is this a known issue? Would it help if I either a) document the problems with the examples as I go through them or b) attempt to fix them? Thanks, Brian Chrisman
Hi Brian, The examples in question are currently generated from the programming guide. The idea was that it would be easier to keep them up to date this way. However the effect is that some examples don't work. It's probably better to maintain the docs and samples as separate units. It would be great if you could update and fix them as you go through them! Some of the examples only make sense in the context of the programming guide, and should probably be removed. Others just need a bit of tweaking. If you send me an updated set I'll make sure it goes on the website. Have you otherwise had a look at the XML.com article? You might find it useful/interesting. Links to the article and the examples it covers are available here: http://www.o-xml.org/news/22-jul-2004.html Thanks for helping out, regards, /m On 6 Apr 2005, at 7:35, Brian Chrisman wrote: > I was running through the example .oml's in the > zip archive on the o-xml.org web site. Got them > running for the most part (debian/kaffe), but a > few of them seem to have errors. One in particular, > chapter-8.oml is not well formed XML.(Continue reading)
Hi guys,
I have a simple question regarding your project. I've been following such "executable XML" libraries for sometime now. But recently, XQuery has picked up a lot of momentum. I'd appreciate it if you could explain to me how projects such as yours or Jelly etc are different from XQuery or where one would use o:XML and not XQuery. I still don't know why one would want to write a program in XML and not in simple English-like languages like Java/C.
Thanks,
Ashwin (www.JavaForU.com).
_______________________________________________ o-xml mailing list o-xml@... http://lists.pingdynasty.com/mailman/listinfo/o-xml
On Mon, Apr 18, 2005 at 03:58:56PM -0000, Ashwin Jayaprakash wrote:
> Hi guys,
> I have a simple question regarding your project. I've been following such "executable XML" libraries for
sometime now. But recently, XQuery has picked up a lot of momentum. I'd appreciate it if you could explain
to me how projects such as yours or Jelly etc are different from XQuery or where one would use o:XML and not
XQuery. I still don't know why one would want to write a program in XML and not in simple English-like
languages like Java/C.
>
I'm not a developer on this project.
I see a couple advantages to an XML syntax language such as this:
- program mutability... XML parsers are well implemented. Creating
code that generates or modifies other code is simplified.
- clear syntax.. one thing I like about XSLt (and by extension, o:xml)
is the explicit delimiters for code blocks. To me:
<xsl:if test="(expression)">
(bunch 'o stuff)
</xsl:if>
is more clear than
if ( (expression) ) {
(bunch 'o stuff)
}
... particularly when nested.
This is more of a style preference though, not as compelling
as the former reason.
- syntax error issues. Many of what would normally be syntax
errors determined by the compiler, can be picked up by verifying
a program against an XSD schema document. Probably makes it
easier for those writing compilers?
-Brian Chrisman
> Thanks,
> Ashwin (www.JavaForU.com).
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> o-xml mailing list
> o-xml@...
> http://lists.pingdynasty.com/mailman/listinfo/o-xml
On Mon, Apr 18, 2005 at 06:25:05PM -0700, Brian Chrisman wrote: > On Mon, Apr 18, 2005 at 03:58:56PM -0000, Ashwin Jayaprakash wrote: > > [..] > > I still don't know why one would want to write a program in XML and not in simple English-like languages like Java/C. I wouldn't exactly say English-like for those languages, as they can be quite cryptic at times. But I have the same opinion about writing programs directly in XML. So far I haven't met any compelling reasons to do so. > I'm not a developer on this project. Neither am I. I am a developer of the SrcML (www.srcml.de) project however, which has a few things in common with o:XML as you will see further below. > I see a couple advantages to an XML syntax language such as this: > - program mutability... XML parsers are well implemented. Creating > code that generates or modifies other code is simplified. What we have here is a mixing of two elements: 1) Code storage and 2) Code modification (aka programming) The SrcML project is also using XML as a means of storing a program's source code. The difference to o:XML however is that we don't expect programmers to directly work on this XML representation. So your point is true of course, but it is already achievable through storing code in XML. Writing new code to generate and modify other code can take advantage of the stored code being stored in XML. There is no real reason though why the new code should be written in XML too (but of course it should be stored in XML again). > - clear syntax.. one thing I like about XSLt (and by extension, o:xml) > is the explicit delimiters for code blocks. To me: > <xsl:if test="(expression)"> > (bunch 'o stuff) > </xsl:if> > is more clear than > if ( (expression) ) { > (bunch 'o stuff) > } > ... particularly when nested. > This is more of a style preference though, not as compelling > as the former reason. I personally prefer the approach python takes to this (eliminating delimiters by making whitespace responsible for the blocks): if expression: bunch of stuff else: other stuff Of course this is a personal preference as you already pointed out. I think however that it might not be the best idea to demand from programmers to write their code in XML simply because '</xsl:if>' is easier to see as a delimiter than '}'. If that was the case we could just as well redefine an existing syntax to use 'endif' or anything else which is 'more clear'. I think it is not the syntax becoming clear in XML, but rather the semantics. Storing your java code in XML takes a lot more space and the reason is not only that XML tags are longer, but because you make semantic information explicitly available. Let's take a look at this simple expression: a = (SomeClass)v.getSomething(); This is how it translates to SrcML (as I know more about it than o:XML or rather MLML in this case, but the idea remains the same): <expr> <assignment operator="assign"> <lvalue> <expr> <var_use name="a"/> </expr> </lvalue> <rvalue> <expr> <typecast> <type name="SomeClass"/> <expr> <obj_access type="method" name="getSomething"> <object> <expr> <identifier name="v"/> </expr> </object> <arguments/> </obj_access> </expr> </typecast> </expr> </rvalue> </assignment> </expr> This takes up quite a lot more space now, but look at the information which is now explicitly available. Of course all this information was right there at the start, but if you want to write a program making use of this information it has now become a lot easier. The program can easily find out that we have an assignment here, what left and right values are, that a typecast and a method call is involved, etc etc. This is also a point, where you have to decide what you want to do with that XML representation. If you want to use it as you pointed out in your first argument - to write code to generate and modify other code - then you will be glad to have direct access to all the semantic informations. If you want to write your code in XML directly you will of course not be happy about having to write everything in such explicit detail. > - syntax error issues. Many of what would normally be syntax > errors determined by the compiler, can be picked up by verifying > a program against an XSD schema document. Probably makes it > easier for those writing compilers? Again a reason to store programs in XML. And yes it does make it easier for those writing compilers, as the frontend parser is no longer neccessary (or rather replaced by a commonplace XML parser). If you don't write the programs directly in XML though it comes at the cost of an additional parser being needed to perform the translation to XML. If you write the programs directly in XML it makes it easier for compiler writers too, compared to writing them in Java/C/... However I think this is an irrelevant point when deciding whether to write code in XML or not. A programmer does not decide to use a language because those who have written the compiler for it had an easy time. Why not all use brainfuck then? Finding syntax errors is trivial and a full blown compiler takes less than a hundred lines. But it's obvious that no one wants to write programs in brainfuck just because compiling it is so nice. -- -- Raiser, Frank Student <at> University of Ulm (www.uni-ulm.de) There are no significant bugs in our released software that any significant number of users want fixed. (Bill Gates)
On Tue, Apr 19, 2005 at 05:34:56PM +0200, Frank Raiser wrote: > On Mon, Apr 18, 2005 at 06:25:05PM -0700, Brian Chrisman wrote: > > On Mon, Apr 18, 2005 at 03:58:56PM -0000, Ashwin Jayaprakash wrote: > > - syntax error issues. Many of what would normally be syntax > > errors determined by the compiler, can be picked up by verifying > > a program against an XSD schema document. Probably makes it > > easier for those writing compilers? > > Again a reason to store programs in XML. And yes it does make it easier for > those writing compilers, as the frontend parser is no longer neccessary (or > rather replaced by a commonplace XML parser). If you don't write the programs > directly in XML though it comes at the cost of an additional parser being > needed to perform the translation to XML. > > If you write the programs directly in XML it makes it easier for compiler > writers too, compared to writing them in Java/C/... However I think this > is an irrelevant point when deciding whether to write code in XML or not. A > programmer does not decide to use a language because those who have written > the compiler for it had an easy time. Why not all use brainfuck then? Finding > syntax errors is trivial and a full blown compiler takes less than a hundred > lines. But it's obvious that no one wants to write programs in brainfuck just > because compiling it is so nice. I'm in pretty much violent agreement with all your points. Choosing a language for which it is relatively easy to write a compiler allows you greater choice in whose compiler you will use and what features will be available. I think if I were to write a non-XML-syntax language right now, I'd pre-parse it into an XML document anyways.... Brainfsck may be a logical extrema in this argument, but we're generally talking about useful languages, I think.. :) btw, have you (or for that matter, anybody) heard of any source management systems that are tailored for XML-language development? In particular, I thought it would be pretty nice to have such a system that will report context of changes made... some such systems do this for other languages... -Brian
On Tue, Apr 19, 2005 at 10:41:27PM +0000, Brian Chrisman wrote: > I'm in pretty much violent agreement with all your points. > Choosing a language for which it is relatively easy to write > a compiler allows you greater choice in whose compiler you > will use and what features will be available. I think if I > were to write a non-XML-syntax language right now, I'd pre-parse > it into an XML document anyways.... Brainfsck may be a logical > extrema in this argument, but we're generally talking about > useful languages, I think.. :) Thinking one step further here will probably lead you towards compilers with a plugin architecture. Currently we can only choose between compilers from different vendors, but assuming an easily parseable XML as the base there's a wide range of possible improvements that could easily be incorporated into a compiler framework through plugins. > btw, have you (or for that matter, anybody) heard of any source management > systems that are tailored for XML-language development? > In particular, I thought it would be pretty nice to have such a system > that will report context of changes made... some such systems do this > for other languages... No.. and yes :) I haven't heard of an existing one yet, but the SrcML project is currently a university project here with several students developing applications on top of the SrcML representation (and the provided API). One of those projects is a source code management system which takes advantage of storing the code in XML. But I suggest you don't hold your breath, as it will at least take a semester before it's useable and I don't know whether it will actually reach a production state at all. However I'd appreciate if you could get into more details about what you expect from such a system. What kind of queries would you want it to be able to answer for example, where do you see the major advantages to line-based SCMs, etc. I suggest you answer to me directly or through the srcml-discussion list, as this isn't related to o:XML now anymore. -- -- Raiser, Frank Student <at> University of Ulm (www.uni-ulm.de) Get and set methods are evil. (Allen Holub)
Hello Ashwin, This has already to some extent been covered in replies from Brian and Frank, but I think it's worth noting the difference between XQuery and languages such as o:XML. XQuery is not a general-purpose language, it's purpose is quite specific. It's true that it can be used for many other purposes aside from that intended, but doing so usually requires a great deal of inventiveness and bending of the paradigm. Similarly to how for example XSLT can be used as a general-purpose language, if you really want to. XQuery, unlike XSLT and o:XML, is not itself encoded in XML. It's a text and keyword based language, with constructs for generating XML output. This hybrid approach is interesting, but doesn't bring the advantages of XML-based languages that Frank and Brian describe. Instead XQuery has the same limitations as other keyword-based languages. The way I see it o:XML has two key benefits: 1) XML-based source code that can be computer processed and/or hand-edited, similarly to XSLT. 2) Object-oriented, XPath-based expression language. A benefit of 1) is that code can be very easily generated, for example by code wizards or from high-level descriptions. Writing o:XML programs that generate other programs is equally simple. Another consequence of 1) is that o:XML code can be processed by analysis tools, or used to generate documentation and UML models, or integrated with eg Aspect or Design by Contract paradigms etc. The sky really is the limit, and writing tools using off-the-shelf XML processing components is easy - UML roundtripping for o:XML was achieved within 2-3 days of XSL coding. Finally, the XML format is extensible, which means that rich documentation, meta-information (eg deployment descriptions), unit tests, requirements etc can live side by side with the code. XML makes the structure of the code transparent, which makes it easy to integrate it within the bigger context of running a software development project. As for 2), I believe that XPath is to XML what SQL is to relational db's, or regular expressions to text. o:Path extends XPath with OO capabilities. Used with a seamless combination of literal and dynamic XML, possible thanks to 1), it makes generating and processing XML easier than with any other language. No DOM, SAX or similar API's necessary, just native XML and o:Path. And o:XML is a general-purpose, full-featured OO language, which can't be bad. /m On 18 Apr 2005, at 16:58, Ashwin Jayaprakash wrote: > Hi guys, > I have a simple question regarding your project. I've been following > such "executable XML" libraries for sometime now. But recently, XQuery > has picked up a lot of momentum. I'd appreciate it if you could > explain to me how projects such as yours or Jelly etc are different > from XQuery or where one would use o:XML and not XQuery. I still don't > know why one would want to write a program in XML and not in simple > English-like languages like Java/C. > > Thanks, > Ashwin (www.JavaForU.com).
RSS Feed1 | |
|---|---|
4 | |
3 | |
10 | |
4 | |
15 | |
3 | |
5 | |
6 | |
3 | |
6 | |
5 | |
1 | |
4 | |
2 | |
3 | |
1 | |
2 | |
2 | |
5 | |
8 | |
6 | |
24 | |
14 | |
6 | |
10 | |
6 | |
10 | |
11 | |
3 | |
2 | |
1 | |
3 | |
1 | |
1 | |
2 | |
2 | |
2 | |
3 | |
5 | |
29 | |
9 | |
13 | |
3 | |
18 |
