On Sun, 16 Dec 2001, Stefano Mazzocchi wrote:
> 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).
But sure the attributes.
> I mean, your schema defines the tag names, just like the language syntax
> defines keywords.
Yup.
> Then, languages doesn't (normally) rule what variable names you can
> choose, as well as you can't force attribute values (or validate them).
Values, yes, and they are not validate by Schema but by the interpreter.
But unlike languages you can define the names of the function arguments
(which are the attribute names in markup languages).
> 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 don't believe you havn't got my arguments :( You already wrote it! You
*have* to use the "type" and the "src" attributes to write a valid
map:generate element. Did you see now? The schema can force you to use
those attributes. Sure, the values need to be validated by the
interpreter anyway.
I think
<keyword name-for-a="a" name-for-b="b"/>
is much more verbose but also much more readable and understandable than
keyword(a, b);
> > > 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.
It's not primarly the Scheme syntax (admittedly, it's ugly) it's more
that we introduce another syntax beside XML and Java. That's what make
me worry about it and ...
> My point is: since the flowmaps will very likely require lots of code
... this is exaclty the point I'm not sure about that. I've still not
seen the requirement of "lots of code". Lots of code can mean "many
lines" but it doesn't say anything about the set of keywords needed. I'd
like to see how many "function" or "keywords" we have to introduce to be
able to describe a flowmap. This is the factor of using a full fledged
programming language syntax or a simple markup. Remember the examples
from Gabriela and Berin about their flowmaps. They had at most 10-15
keywords to describe it.
> and very few markup content (actually, should have *NONE*), why
> shouldn't we use a code-oriented syntax for them?
see above.
> 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)
>
> Now: would you -1 that as well?
Today, yes. Nobody has proven the need for procedural language syntax to
describe a flowmap so far.
Sorry, it's like me being a PITA in this thread but I think I've made
my reasons to be so clear ;)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
