OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] XUL Compact Syntax Study Now Online - Is XML too hard for

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


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

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.


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.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS