Rushforth, Peter wrote:
> I think there's  a lot of value in such interfaces.  It would be nice
> if it didn't involve having to write a parser each time, but the cost
> is not too high, I think
>   
Yes. XML standards and tools took a gigantic step backwards in that 
regard, and have never recovered or tried to take that use case 
seriously. The explosion in new uses allows us to treat that kind of use 
as niche or external, rather than intrinsic.

In the SGML days, the world for system integration was pretty much 
divided into

  1) Those who used SGMLS/SP.  People who required free tools, and had 
SGML data.

  2) Those who used Perl. People who required free tools, and had 
non-SGML data they wanted hack like it was SGML (often then morphing 
into the first type)

  3) Those who used OmniMark. This was people who could pay for a tool.

The thing about OmniMark was that it had a built-in text processor, so 
that non-SGML files could be marked up to spec on demand. 

Furthermore, the input processing, the parsing and the output processing 
was implemented using co-routines, so it was possible to process the 
input differently depending on the currently generated element context.  
This overcame a problem that affects systems based on piping the output 
of a text-to-markup process into a markup-transformation process, that 
for any kind of complex input you may need to have grammar-dependent 
input processing: In the case of OmniMark, the unminimized markup could 
be used to guide processing both the input and the output; in a pipeline 
solution you would need to specify the grammar for the text-to-markup 
converter explicitly, which could be double handling.

In the early days of XML, some of the early proponents were very keen 
that it should be a universal format, and therefore up-translations 
(text to XML) were regarded as unsound  and wrong-headed. IMHO when this 
goes beyond expert opinion shaping the direction of a technology to 
experts denying the use cases of a population, it goes beyond expertise 
and starts to smack of arrogance (I have the same opinion about binary 
Efficient XML Interchange: I don't like it, I am not convinced, I 
couldn't be bothered to help, but if they think they have a use case who 
the hell am I to tell them otherwise or campaign against their spec or 
block it on some committee?)

Cheers
Rick Jelliffe

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php