Harpoon Data Language: "One Syntax to Rule Them All"

[mczard]

I have created a data language, which I think solves many XML
deficiences. The key points are:

Data model:
XML - elements and attribues
Harpoon - tagged lists, records and tuples (compatible with
programming languages)

Notation:
XML - not appropriate for all applications (XPath, XML Schema)
Harpoon - no need for any other syntax; syntactic sugar solves the
problem (one syntax to rule them all!)

Verification:
XML - XML Schema, Relax NG etc.
Harpoon - data types, as in the programming languages

Target:
XML - document publishing
Harpoon - data files and application scripts

I would like to ask you for comments and opinions.

Harpoon is here:
http://harpoon.sourceforge.net

 

[Joseph Kesselman]

Wheel (n): A device so useful that everyone feels compelled to invent
their own.

 

[mczard]

Wheel (n): A device so useful that everyone feels compelled to invent

their own.

I am not reinventing, I am redesigning to fix defects of the original
design.

 

[Joseph Kesselman]

I am not reinventing, I am redesigning to fix defects of the original
design.

One man's defect is another man's feature is another man's compromise.

If XML doesn't suit your needs, by all means design an alternative which
does. Just don't expect a lot of uptake. XML *is* the result of a lot of
painful compromise, but for that very reason it has mindshare. Getting
the same kind of uptake on anything else is likely to take many years,
just as it took many years for XML to reach this point.

You may have better luck if you can document how your syntax maps to the
XML Infoset, which would tell folks how to cleanly map it into and out
of the existing XML world. But if it does map cleanly, it proably isn't
different enough to be worth pursuing.

I haven't looked at your proposal in detail, partly for time reasons and
partly because I disagree with your stated key points -- for example, I
don't agree that XML is oriented solely toward "document publishing",
nor do I see a great deal of difference between schema languages and
"data types as in the programming language".

 

[mczard]

You may have better luck if you can document how your syntax maps to the
XML Infoset [...]

There is no direct 1-to-1 mapping, because Harpoon is very different
than XML.

[...] I disagree with your stated key points [...]

Now I see I have missed an important introduction - I assumend that
it is quite obvious that XML has some very important deficiences.

I think these are:

[1] XML is too clumsy to be used for XPath, XML Schema and many
other languages. Programming with the XML syntax sounds like
an insane idea.

[2] XML is very inappropriate for typing without a dedicated editor.

[3] XML's data model with its elements and attributes is oriented
on text documents and is incompatible with data types found
in programming languages. It is also often very unclear how some
data should be represented with elements and attributes.

I wanted to ask if it was convincing that Harpoon is better at least
in the 3 above areas.

 

[Joseph Kesselman]

Now I see I have missed an important introduction - I assumend that
it is quite obvious that XML has some very important deficiences.
> I wanted to ask if it was convincing that Harpoon is better at least
> in [the specified] areas.

Well, it isn't obvious that these are serious deficiencies given the way
XML is actually used. I'll try to find time to glance at Harpoon some
time in the next several weeks, but just to indicate where I'm coming from:

[1] XML is too clumsy to be used for XPath, XML Schema and many
other languages. Programming with the XML syntax sounds like
an insane idea.

Depends on what your programming language looks like. Check out the
various publications on XSLT (which is of course a programming
language), Bean Markup Language (a programmable "bean box"), etc. I
wouldn't want to write assembler in XML syntax... but a suitably
high-level language really isn't bad.

It's also much less than clear that anyone other than a Lisp bigot (of
which I are one) or someone writing embedded scripts actually wants
their programming language to use the same syntax as their data.

[2] XML is very inappropriate for typing without a dedicated editor.

I disagree with the "very", and I would submit that this is a back-end
versus front-end issue. Not many people actually want to type data files
directly into the machine; most data is either generated, or entered via
some form of editor suited to that kind of information. XML is
human-editable and human-debuggable at need, and that's a good thing
because it makes developing and debugging code a heck of a lot easier,
but the end-users don't care and shouldn't have to.

[3] XML's data model with its elements and attributes is oriented
on text documents and is incompatible with data types found
in programming languages. It is also often very unclear how some
data should be represented with elements and attributes.

Hm? See XML Schema, which provides a formalism for mapping
elements/attributes to more program-like datatypes. See also the many
existing "data binding" tools which map between XML and other back-ends.
BTW, if you aren't sure about whether to use attributes, the simple
answer is "don't"; they're a convenience, not a necessity... But the
fact is that in *ANY* data representation there are often multiple good
choices of how to map concepts to actual structures, and part of being a
decent designer is understanding how those trade off.

 

[Andy Dingley]

[2] XML is very inappropriate for typing without a dedicated editor.

I disagree with the "very", and I would submit that this is a back-end
versus front-end issue. Not many people actually want to type data files
directly into the machine;

Most programmers do spend a large portion of their time doing this,
and programmers do get to choose technology platforms.

I might not like typing XML all day, but it beats the hell out of
unreliable CSV, fixed-width text fields, magic binary formats with
proprietary editors or even punching cards. I might never expect my
users to work directly with XML, but _my_ ability to do so when
necessary is one of my very favourite things about it.

 

[mczard]

I might not like typing XML all day, but it beats the hell out of

unreliable CSV, fixed-width text fields, magic binary formats with
proprietary editors or even punching cards. I might never expect my
users to work directly with XML, but _my_ ability to do so when
necessary is one of my very favourite things about it.

I think (and want to convince other people) that there is place for
more than one data language, exactly as there is place for many
programming languages. XML was originally designed for adding
meta-level information to textual documents. It is also good for
automatic information exchange between services. On the other
hand Harpoon, as I think, is more suitable for manually edited
complicated configuration files and user-defined scripting
languages. I would recommend Harpoon especially when one is
going to create his/her own language for advanced configuration
of an application. Harpoon is a half-ready solution then - the
syntax is ready, user only has to define the semantics.

 

[Joseph Kesselman]

I think (and want to convince other people) that there is place for
more than one data language

Sure. But XML's greatest values are precisely derived from the fact that
it is a single shared data language. That means it has gotten a lot of
tooling work already done which everyone can share, and it means that
data files are interchangable between tools and machines are platforms.

On the back end, or for situations where those features aren't of high
value, by all means use whatever makes sense. XML isn't intended to
obviate the need for application-specific data representations, or for
databases (though having databases which can directly manipulate XML (or
XML-infoset-like) structure does have its own value for some tasks,
which is why that capability was added to DB2).

After a fast look: Harpoon's not a bad example of an abstract syntax. It
needs to go find a killer application to test itself against the real
world, so it rediscovers things like formal data typing and named types
and namespacing and all the rest that XML had to be retrofitted with,
and establishes that it can survive contact with the Real World. If it
turns out to be brilliantly successful in one small corner, it might get
some attention.

Until then: It's one more of a long family. Worth publishing as a set of
ideas, but I don't see anything that makes it more interesting than any
other member of the family.

Have fun with it.

 

[mczard]

Until then: It's one more of a long family.

Could you tell me what family you are talking about?
I would like to know what languages you have in mind.

 

[Joseph Kesselman]

Could you tell me what family you are talking about?
I would like to know what languages you have in mind.

Check the academic literature; abstract syntax has a fairly long history.