ebxml-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: standarisation: UML or XML?
- From: a.gomez.corona@ibermatica.com (Alberto Gomez Corona)
- To: "'ebxml-core@lists.oasis-open.org'" <ebxml-core@lists.oasis-open.org>
- Date: Mon, 21 Feb 2000 12:29:05 +0100
Hi.
First, I´m
"concerned" about the initial focus of this Forum, about defining standard
messages. I want to higlight some remarks, learn from myself from the tremendous
success of the Web and the not so well evolvement of apparently better
structured information exchange architectures, such is CORBA, COM
etc.
And here I want
introduce the notion of document computing. For me, a document can be seen as
the exposition of a object data to anther piece of software. Instead of offering
a given interface, a document is an object which shares
itself.
What advantages such
object has in terms of standarisation and evolution (two apparently opposite
features)?
first, XML, the base
format, can be standarised for any information exchange need. and, there are
standard procedures to extend , re-define , formally fix and publish to the
internationa community since the beginning.
If we implement the
document visiblity to the external world trough an object oriented API, we
may give away these well proven features, and we may be invloved in re-solve the
problem: wether UML must be used or not etc.
If we use XML only
as another way to serialize binary data, we will drop out the tremendous
capablilities of XML as a way to standarize and to make evolvable the
information about the status and the bussinees processes of a
enterprise.
A document
describing the product catalog of a company can be used on infinite ways
(discovered or undiscovered yet). A Interface to access the product catalog
of a company only can be used the way it was designed to be used. I may be very
open, but never more open that the document itself.
To sumarize,
what I propose is the following:
In any client-server
scenario, to expose the server side of the interaction as a document (XML) . In
the client side, to use an standard API (such is XML-DOM or XSLT) and to code
the process specific code over the former ifrastructure. That domain specific
code will be subject of standarisation after the the supporting data has been
standarised. That is, the first priority is the schemas, DTDs and so on of the
XML documents to use. The standarisation of the procedure for each individual
process can be done by the market.
Maybe this message
can have some utility.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC