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

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: APIs, messaging



I agree with this insofar as the design of *communicating systems* 
is concerned.

But swirl of threads this week on object OR data design are 
troubling me with regard to the tools.  Here's why.  If 
one starts out with RDF or UML, one is almost immediately 
into class design and by a slippery slope, designing an 
application language based on object-oriented classes.  That 
may not be what is wanted.  It depends on the use one 
has for a tag that has a typeOf attribute somewhere 
in it.   What is really being said?  Is it:

o Find this class and inherit its methods or interfaces (compile this)
o Find this formal description and validate this against it (check the
structure)
o Interpret this as one of those and do what you do based (just do something
When or If)
  on that interpretation. 

Any or all?  

The critical question: by what criteria does one choose to create a UML 
description, or an RDF Description, or a Topic Map, or just an XML Schema?
God forbid, infoSet gets tossed in there.

Len Bullard
Intergraph Public Safety
clbullar@ingr.com
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Francis Norton [mailto:francis@redrice.com]

"Simon St.Laurent" wrote:
> 
> XML offers computing the opportunity to behave much more like the "real
> world", where communications is inexact and messy and the
> standardization costs are only borne if there's a real benefit to
> standardization.  (ISO standardizes shipping container construction, not
> which contents are appropriate to containers.)

I agree with your analogy but not, I suspect, your conclusion.

We are watching a transition from "close-coupled" comms to
"loosely-coupled" comms.