Re: New win32lib and XML
Pete Lomax wrote:
>
>
>On Mon, 05 Jan 2004 16:07:34 -0600, Isaac Raway
><isaac-topica at blueapples.org> wrote:
>
><snip>
>
>
>>I disagree. /XML /serious method of storing data/verbose.
>>
>>
>Yup. I said "not the worst" for pretty much the same reasons.
>
>
Well, I think the duplication of each tag name is a pretty serious
design flaw it's just sort of stupid...and with propor indentation
(which code generators and programers should do anyway) it's just redundant.
>>2. There is not a clear reason to differentiate between attributes and
>>child nodes
>>
>>
>I'm assuming you mean that:
> (label1=... (font=times)),
> (label2=... (font=times))
>and
> (font=times (label1=...),
> (label2=...))
>
>should be treated identically.
>
>
Well, actually, I meant something like this. I'll use XML because that's
the language where this isn't clear:
This...
<root>
<object name="TestObject" />
</root>
Is conceptually identical to
<root>
<object>
<name>TestObject</name>
</object>
</root>
The reason attributes are needed in XML is because to express an object
purely in terms of elements is far too verbose and repetative. It is
much more compact to use attributes, but the existence of both options
makes the language impure.
I am really interested in purity in languages, so this won't necessarily
bother other people. However, I believe this single fact is an
impediment to a vision we where all given when XML was introduced: that
anyone anywhere will be able to read data formatted as XML and do
something useful with it. But that's not the case, in part because there
are multiple ways to express the same conceptual data structure.
I'd prefer to express the sample object above as a LISP object because
there is really only one way to do it (Once you decide on an over all
structure that is. See below.):
(root
(object
(name "TestObject")
)
)
Also, of course, expressible in terms of a Euphoria sequence.
Note that there has to be some agreed upon standard for how to express
these things in as LISP lists or Eu sequences (which in reality are
almost identical concepts). I don't think I'm actually getting the
syntax right, but in Common LISP there is a consistent and standard way
to express an object that has named slots. I'm sort of assuming that it
is a list with the odd numbered items being the names of the even
numbered object expressions, which may themselves be lists conforming to
the same structure.
><snip>
>
>
>>language that is too verbose is unpleasant to use
>>
>>
>Agreed. Although it may occasionally be handy to edit the file
>directly, a layout editor would obviously be much easier.
>
>
Actually, with an (optional) flow based layout engine (sort of like
Java, shudder) it may be even faster than a layout editor.
>>I'd suggest writing a new form editor, even if Judith's IDE would be
>>easy to convert (which I'm pretty sure it wouldn't be). It's better to
>>have a fresh project that is designed from the ground up for a new
>>format and makes no compromises.
>>
>>
>You're probably right. Count me in. I'll let you start. 
>
>
I'd love to, actually. The thing is, I'm not exactly an all star in
Euphoria. I'd love to have a nice little tool like the old MS Dialog
editors for pre-Word 97. A very simple tool, one window, lightweight.
Want more than one form open for editing? Open more than one copy of the
window. Entirely menu driven interface, no interfering toolbars or
pallets. Right click, context menu (I think...) for each control, popup
properties dialog.
>Some like an all-in-one IDE style solution; I prefer several small
>distinct tools. Short term, I'll continue looking on the web.
>
>
I tend to the multiple tools department when it comes to languages like
Euphoria. I prefer an IDE for VC++ and VB because they are designed for
IDEs.
>I'm not the slightest bit worried about pre-processing xml/ lisp/
>Eu-sequence style before throwing it at (eg) Derek's new win32lib. As
>far as I'm concerned, XML is portable, unambiguous, easily parsed and
>easily translated. So are lisp and Eu-sequence style. I'll defer my
>final decision on which as long as possible, maybe even go with
>supporting any of the above.
>
>
Well, how about this. Create a middle layer with a data file spec that
allows people to add support for whatever structured data format they
like? Along with a tool to translate between the formats (as long as you
have the data file for both the formats you want to move between), the
better one would emerge as the leader. Well, at least the one people are
most comfortable with, which may in fact not be the better one. Heh.
LISP has always been better, but almost no one (including me, who thinks
it's better) uses is very much. The world had a structured data language
a very long time before XML came out. It's sad really...but oh well.
Perhaps we can bring it back a little tiny bit?
>
>
|
Not Categorized, Please Help
|
|
