RE: [xml-dev] Feasibility of "do all application coding in the XML langu

["Rushforth, Peter" <Peter.Rushforth@NRCan-RNCan.gc.ca>]

Hi Rick,

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

It would be good for the XSLT language, and perhaps others,
if a general mechanism for generating a parser was possible.  
I was at a loss to think what that mechanism might be, but I see 
you are describing one such approach taken by OmniMark.

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

I'm certainly not against paying for tools!  But to help XSLT 
gain traction it is necessary to make something generally useful 
available for free.  Maybe more free stuff will be available if 
the base of users gets bigger.

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

I like the idea!  Kind of like the text-to-spreadsheet wizards you
see, only any given (binary) thing to XML (well maybe SAX events).  

Cheers,
Peter Rushforth