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

Discussion in 'XML' started by mczard@poczta.onet.pl, Mar 17, 2008.

  1. Guest

    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

    --
    Micha³ Czardybon
     
    , Mar 17, 2008
    #1
    1. Advertising

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

    --
    Joe Kesselman / Beware the fury of a patient man. -- John Dryden
     
    Joseph Kesselman, Mar 17, 2008
    #2
    1. Advertising

  3. Guest

    > 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.

    --
    Michal Czardybon
     
    , Mar 17, 2008
    #3
  4. wrote:
    > 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".

    --
    Joe Kesselman / Beware the fury of a patient man. -- John Dryden
     
    Joseph Kesselman, Mar 17, 2008
    #4
  5. Guest


    > 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.

    --
    Michal Czardybon
     
    , Mar 17, 2008
    #5
  6. wrote:
    > 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.






    >
    > --
    > Michal Czardybon
    >



    --
    Joe Kesselman / Beware the fury of a patient man. -- John Dryden
     
    Joseph Kesselman, Mar 17, 2008
    #6
  7. Andy Dingley Guest

    On 17 Mar, 20:17, Joseph Kesselman <> wrote:

    > > [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.
     
    Andy Dingley, Mar 19, 2008
    #7
  8. Guest

    > 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.

    --
    Michal Czardybon
     
    , Mar 19, 2008
    #8
  9. wrote:
    > 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.

    --
    Joe Kesselman / Beware the fury of a patient man. -- John Dryden
     
    Joseph Kesselman, Mar 19, 2008
    #9
  10. Guest

    On 19 Mar, 22:36, Joseph Kesselman <> wrote:

    > 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.

    --
    Michal Czardybon
     
    , Mar 20, 2008
    #10
  11. wrote:
    > 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.


    --
    Joe Kesselman / Beware the fury of a patient man. -- John Dryden
     
    Joseph Kesselman, Mar 20, 2008
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ed
    Replies:
    24
    Views:
    1,067
    Dimitri Maziuk
    Mar 27, 2006
  2. DaveInSidney
    Replies:
    0
    Views:
    461
    DaveInSidney
    May 9, 2005
  3. pabbu
    Replies:
    8
    Views:
    771
    Marc Boyer
    Nov 7, 2005
  4. Shravani
    Replies:
    8
    Views:
    828
    Bartc
    Mar 16, 2008
  5. Replies:
    28
    Views:
    1,213
Loading...

Share This Page