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] Web Design Principles (was Re: [xml-dev] Generality ofHTTP

[ Lists Home | Date Index | Thread Index ]

Actually, we do.  When we have a COM object passing data 
to another program, it works fine.  When we have a 
customer with a technical person who acts as the authoritative 
contact for the duration of the project, it works fine. 
If we have a reasonably well-understood data standard and 
a lot of users, migrating from comma delimited to XML is 
fine. When we want to get away from byte counting, and 
need to check some co-occurrence constraints, we can 
add some Schematron assertions, and it works fine.  

There are alternatives to all of the above and case 
by case, we use any or all of them.  It is the assumptions 
about HTTP ubiquity that are troubling; so as long as 
XML doesn't directly depend on HTTP, that's OK too because 
there are cases for which HTTP.... works fine.  Human 
in the loop systems can work with XML just fine, but the 
customer pays for there time.

No size fits all.  Some sizes fit most but not comfortably.

It's the web services that we need to work predictably and will 
have to be quite cautious about how and where we use them. 
Today, they look like a good idea for low frequency, coarse transactions 
outside the real time loop.  We have plenty of those too, but 
they aren't mission critical where I would limit that term to the 
life-preserving operations.  On the other hand, something 
like neighborhood watch, court systems, forensic systems, 
these are good candidates because they tend to not be 
co-located and often have multiple vendors we need to 
work with because we do not try to provide all of the 
possible products for a market (not a reasonable choice).


-----Original Message-----
From: Mike Champion [mailto:mc@xegesis.org]

Admittedly, this is essentially a matter of perspective, not 
technology.  It might be hard to look at the code for a real system 
and determine whether it was "object centric" or "XML centric."  
Furthermore, the "XML is just a serialization format for my well-
defined objects" approach has a lot of good use cases.  There ain't 
no WAY I'm going to try to persuade Len Bullard not to use it for the 
kinds of highly-designed, tightly-coupled mission-critical systems 
one hopes that the military and public safety agencies deploy. 


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

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