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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Integration Models (WAS RE: [xml-dev] parser models)

[ Lists Home | Date Index | Thread Index ]

That is one of those interesting conundrums of 
the current XML zeitgeist.  Given the Infoset 
definitions and subsequent APIs, one may be 
programming to an XML data model but never 
actually passing a single pointy bracketed 
bit of data.  Contrast this to the current 
zeitgeist where some, quick to hit the coding 
keys but tardy to RTFM, use XML as a super 
ASCII delimited file that is dumped to a 
known directory location and sucked into the 
next processor.  These are distinctly different 
integration models, IMHO.

Is there a confusion between loose coupling 
as an API/data model and loose coupling as file 
types on the wire?  While both are viable, I 
wonder if we would have the same confusion if 
the InfoSet were taught before the syntax. 
On the other hand, how many systems work as 
described, that is, by focusing up front on 
the InfoSet and leaving the syntax for those 
cases where one is actually exchanging a file.

len


From: Paul Brown [mailto:prb@fivesight.com]

I am of the opinion that SAX, ((J?D)|X)OM, etc. are all aspirants for a "service-oriented" architecture for document processing.  In my world, XML is one of the least-likely inputs -- well-formed or not -- and outputs, but the generic functionality provided by XML tools -- data type/structural expression/validation, structural rearrangement (e.g., XSLT), etc. -- is of significant value.




 

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

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