xml-dev - Request for advice defining an XML based syntax

[John Gossman <JohnGo@asymetrix.com>]

>
>
>
>    To make a long story short:  I have been developing a file format for
>data exchange between applications.  The essential purpose is to provide a
>format that objects can stream their persistent state to, for saving or
>exchanging of data.  Further I have a number of criteria for this format: 
>    1.  It must be simple 
>    2.  It must be robust--resistant to data loss 
>    3.  Flexible -- all sorts of data 
>    4.  Extensible -- developers and users can add their own data and
>datatypes 
>    5.  Human readable -- easy to understand 
>    6.  Support versioning easily 
>    7.  Support strong typing--no confusion 
>    I knew from my experience with Autodesk's DXF (Drawing eXchange Format)
>that these goals were achievable, and knew where DXF fell down.  My essential
>idea is data come in two forms--primitive fields and structured records.  For
>primitive fields I realized I needed to store 3 things--type,name, and value.
> The original format I came up with was quite simple, in fact I'll just give
>an example of a button object's data: 
>
>start button 
>    string caption="Click Here" 
>    int left = 50 
>    int right = 100 
>    int top = 80 
>    int bottom = 100 
>end 
>  
>
>    Easy to parse, easy to output, easy to read (helps if you are a
>programmer used to a typed language), and no special characters except the
>almost universally understood '='.  Several of my co-workers asked why I
>didn't use MCF or XML.  My answer was that these formats are two complex, but
>after further study of XML I realized I could make an XML-compliant version
>of the syntax quite easily.  After several iterations I arrived at this: 
>
><button> 
>    <caption string "Click Here"/> 
>    <left    int    50/> 
>    <right  int    100/> 
>    <top    int    80/> 
>    <bottom    int    100/> 
></button> 
>
>    Last week in Montreal, Tim Bray confirmed my suspicion that XML did not
>allow the supression of attribute names as a form of shorthand, which is
>going to necessitate one more change.  However, on further thought, I also
>wonder if I have violated something of the spirit of XML by including all the
>data in attributes--all structure no content.  Option 1 then is the
>following: 
>
><button> 
>    <caption type="string" value="Click Here"/> 
>    <left    type="int"    value="50"/> 
>    <right    type="int"    value="100"/> 
>    <top   type="int"    value="80"/> 
>    <bottom type="int"    value="100"/> 
></button> 
>
>    There is precedent for such a thing, in HTML's IMG tag for example, which
>is an empty tag with all the "data" in attributes.  My question then.  Is
>this better?:
>
><button> 
>    <caption type="string">"Click Here"</caption> 
>    <left    type="int">50</left> 
>    <right    type="int">100</right> 
>    <top   type="int">80</top> 
>    <bottom type="int">100</bottom> 
></button> 
>
>    So, I am asking for the kind the advice of those most familiar with XML.
>Opinions please, either here or by private e-mail (johngo@asymetrix.com), on
>this question or anything else that comes to mind.
>
>    Many thanks in advance, 
>
>    John Gossman 
>    Asymetrix 
>
>    P.S.  The format (which I call OXF for Open Exchange Format) is fully
>defined in a spec written here.  It includes the ability to create data
>schema and use inheritance to extend them, and is specifically designed to be
>non-validating (for robustness:  you don't want to throw away all the data
>because of a few problems).  I would rather not post the spec. until I have
>settled these last few issues, but I will provide a draft for the asking. 
>
>
>
>
>

xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)