[
Lists Home |
Date Index |
Thread Index
]
That is a well-reasoned argument I can accept insofar
as a given tool for creating a given representation for
a given domain of abstractions can create any number
of syntactical representations. Some model editors I
work with in the graphics world provide a local
proprietary format and support some number of one-way
exports into standard formats. The inability to move
these two-way among tools proves to be a significant
problem for rendering and proliferates tools. The
religious issues aside, there is a case for domain
specific tools that facilitate production. The case
for alternative syntaxes is weaker if all they do
is enable faster typing in an ASCII editor. Then
they are just more stuff.
len
From: Kirkham, Pete (UK) [mailto:pete.kirkham@baesystems.com]
As I tried to illustrate with the lisp 'syntax', the added value is in being
able to manipulate the data with a different set of tools and abstractions,
not in a mechanical transform from one encoding to another. Merely eliding
redundant information will gain you a little 'friendliness', as humans are
good at getting meaning from context automatically. But IME the power in a
representation of data is in the abstractions it facilitates and the
patterns it allows the user to observe and create, not the amount of
compression it supports (though compression brings features spacially closer
together so pattern mining becomes easier).
You can't do arithmetic easily with Roman numerals, so the 'compact syntax'
of Arabic numerals was a big gain, but either serve as a datum for a
copyright year. But that didn't mean we started using Arabic script for
language.
Many of the compact syntaxes give a local gain in one domain by directly
supporting the abstractions for that domain, such as RNC, but don't impact
on the general XML case. For XUL, a wisywig editor may be best for the
occasional user, a lisp binding would allow macros to be used for some
abstraction and automation and agile development, and a UML2 HUTN mapping
could give direct model-driven-development support via QVT
(http://qvtp.org/) for the commercial engineers (ie the UML tool thinks it's
a profile of UML rather than the output of a code generator). None of those
are capabilities inherent in XML, nor are they really anything to do with
the syntax.
Pete
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
|
