[
Lists Home |
Date Index |
Thread Index
]
> On Sunday 19 January 2003 17:52, Mike Plusch wrote:
> > Out of the 50 email messages about
> > ConciseXML, almost all of the comments
> > have been of the sort:
> > "but ConciseXML is not XML 1.0!".
> >
> > Although this is a true statement,
> > how about any comments on the two
> > key problems that ConciseXML fixes that
> > are reoccuring issues across the industry.
> >
> > 1. XML 1.0 is verbose and is not suitable
> > for many applications that people would
> > like to use it for. People invent new
> > syntax all the time to avoid XML 1.0.
> > For example, XPATH, XQuery, string
> > encodings, CSV data, etc.
Why is this a bad thing? The software engineering world frequently
rediscovers the value of human factors, and the experence with
programming languages teaches us that humans like a mix of notations
corresponding to the significance of the data: in C family languages
we have comments embedded, infix assignment, prefix function
operators, postfix increment/decrement, explicit end delimites of
lines, start- and end- delimiters for blocks, etc.
I think Mike's argument that we need a new syntax because we don't
want a plurality of syntaxes is wrong: a plurality of syntaxes is
to be expected and should be better supported. Mike leaves out URLs
and dates, from his list of data that avoids XML syntax. When different
kinds of data has different notations, it is easier to figure out what is going
on: when you read an HTML page, you know what is HTML, what is
CSS, what is JavaScript (shudder) and what is PHP; or for that matter,
what is a comment or an element.
> > 2. There is not a single way in XML 1.0 to
> > represent data fields that have a key and value
> > where the key can be any type and the value
> > can be any type.
The concept of data keys is entirely foreign to XML It is not that there
are multiple ways, there is no built-in way. This is a question of layering
and schemas: a key cannote be of any type in raw XML which does not
have "types" in that sense.
But Mike's point is fair: how much should be built in to the base layer?
Cheers
Rick
|
