cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <g-froehl...@gmx.de>
Subject RE: [RT] Managing Flow and Resources
Date Sun, 16 Dec 2001 12:52:53 GMT
>From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
>
>giacomo wrote:
>
>> Well, I have not made myself clear enough. In XML you can control
>> verbosity by DTD/XSchemas/aggreed syntax. The ones controlling the
>> Schemas define the verbosity. In programming language nothing
>> prevents you choosing non-verbose names but in XML we control by
>> Schema the names of elements and attributes.
>
>Yes, but not the attributes (unless you want to extend your own schema
>datatypes).
>
>I mean, your schema defines the tag names, just like the language syntax
>defines keywords.
>
>Then, languages doesn't (normally) rule what variable names you can
>choose, as well as you can't force attribute values (or validate them).
>
>Sure, you might say that we also define the dynamic elements, but this
>is like providing verbose API for your language: you might call
>meaningful API and still do crappy programming. 
>
>Let me show you examples of both:
>
> VerboseObject a = VerboseLibraryFactory.createVerboseObject();
> VerboseValue b = a.getValue();
> int c = b.doSomething();
>
>which is just like
>
> <map:generator type="a" class="my.own.component"/>
> ...
> <map:generate type="a" src="/whatever"/>
>
>I fail to see what XML validation adds to this picture.
>
>> > I can tell you for sure, that both couldn't have used DSSSL because the
>> > unknown syntax would have been too much of a gap for them.
>> 
>> Hey, buddy. Why are you trying to convice me that XSLT isn't the right
>> way to express program logic? I nor anybody else here ever stated to
>> stick with XSLT. I don't understand your digression here. I've simply
>> said that, using your words, that the "web tech population nowadays"
>> understand HTML so there isn't a big step to understand XML and have a
>> syntax that is "procedural" to express logic for flowmaps and I meant
>> that Scheme isn't popular in the "web tech population nowadays" sdo I'm
>> -1 using Scheme syntax. Point.
>
>uh, uh, getting mad :)
>
>Look, I don't like the Scheme syntax as much as you do: without a
>specific editor, it's simply impossible write, so forget about that, I
>would oppose it as well.
>
>My point is: since the flowmaps will very likely require lots of code
>and very few markup content (actually, should have *NONE*), why
>shouldn't we use a code-oriented syntax for them?
>
>I would replace 'code-oriented' syntax with JavaScript (since we have
>parsers available) or any syntax that we can agree on (but i don't see
>the need reinvent the wheel)

IMHO don't use XML to create a programming language. 

"The Extensible Markup Language (XML) is the universal 
format for structured documents and data on the Web." 
-- W3C XML Web site, 2000-07-06

Exactly for _documents_ and in further sense for data!

A little story:
For the AvalonDB we started to define our own SQL in XML,
because we thought that writing a full fledged SQL Parser
is really hard. But what we done was to re-inventing the wheel.
We had to make decision about the syntax, semantic and s.o.
But the syntax for SQL is there. I don't know, since 20 years?
Then I started to write my own SQL Parser with JavaCC. And wow
one week later most of the parser was implemented. Writing
a own Syntax in BNF Grammer or whatever isn't that hard!
Parsing the "where" condition was easier to implement with JavaCC
as in XML!!

This JavaScript idea I like. There are good parser around and
look at:
http://www-124.ibm.com/developerworks/projects/bsf

Do not mix up with BSE ;-))

my 2 Cents

  Gerhard
 
-----------------------------------------------------
That must be wonderful! I don't understand it at all.
-----------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message