Re: BLD -> XML serialization

Sandro Hawke wrote:
> [ I finally caught up on these threads, and looked over your generated
> grammar html files...    no particular comment except this one, right
> now. ]

Hi Sandro.

Thanks for you comments... Since no one had so far made any comment
in response to my mail, I was starting to wonder whether it was worth
my investing time in pressing myself to polish up this tool in view of
other priorities piling up on me ...

>> My overall comments: in general, I find the current serialization style
>> uselessly verbose with redundant tag nestings. IMHO it should be made
>> terser and clearer. I know that this follows a fully-striped style based
>> on the EBNF.
> What kind of code do you use to go between objects and XML?  (I ask,
> to help understand why the verbosity is "useless" and "redundant".)

I am not sure of what you mean. My worry is that we define an XML style
based on an EBNF. As you know, given a CF language there are infinitely
many (more or less wordy) EBNFs that may be given to present its syntax.
Defining the XML serialization style based on an EBNF is a bit like
building a concrete building on sandy grounds: in other words, maybe
full-striping from an EBNF is a systematic non-ambiguous procedure,
but the base it starts from (the EBNF) is everything but unique,
minimal, nor unambiguous!

Useless and redundant for me is the systematic double-wrapping of
all syntactic constructs as well and not using attributes at all
in the representation. The choice of tags as well should preferably
be complete rather than abbreviations. Perhaps all this is a matter
of taste, but it would be timely to experiment with alternatives
using such a tool as my metacompiler where it is easy to change a
couple of annotations in the BNF to produce any style of serialization
we wish to play with.

> Would it be easy enough to make a version of the BNF->XML table which
> showed the nicer serializations you're thinking of?  It would make a fun
> contrast to the version with the RDF/XML serializations.      (it's kind
> of tedious to do the whole table, though, maybe.)

This is a good idea and would take yet another SMOP (small matter of
programming) on my slate. But I see what you mean and I can surely do
it if you think that it would serve/help/interest this WG.

>     -- Sandro

Hassan At-Kaci  *  ILOG, Inc. - Product Division R&D

Received on Monday, 12 May 2008 16:19:13 UTC