Claus, Thanks for the comments. However, having
interface is often regarded as not good enough.
businesses evolves, new partners, activity, rules
will drive the schema
to evolve along the business change. In this
regards, CORBA and
RMI is usually considered a little brittle, not
well suited for app integration.
I heard cases where two RMI had trouble conversing
with each other :(.
I think XML is a step forward from that point of
view. But every pros has
a con, a bottle is half empty of half
----- Original Message -----
Sent: Tuesday, August 10, 2004 11:42
Subject: Re: [architecture] Fwd: greeting
"Jimmy zhang" <jzhang@xxxxxxxxxxxxxx> schrieb am
Thanks for the email. Whether XML is human-readable has
> to do the very meaning of
"human-readable." I think that what
makes XML unique is the combination of open, interoperable,
> loose-coupling and (almost) human-readable.
You just confirmed my point here.
> means that, similar to HTML, a Web
services application will
> have the
option of processing only what it intends to understand
> and process, and disregard other parts of the contend, and
> break the application.
> The same thing can't be said of RMI
> CORBA, which must have a schema
before hand. The problem
> is that when
people changes implementation, they inevitably
> have to the change the data itself, which breaks
No, only when they change
interfaces ; -- and they know they must
> For Enterprise App Integation,
interoprability is the most
thing, XML is *ideally" suited for that.
I think that is still a subject matter under dispute. No
XML has a lot to offer -- but *ideally*
is too much of a claim.
> had a very article on
Let me know what you think of it.
would not recommend reading that article: it's too shallow.
I can find no proof in the above article for the
claim that XML
would be *ideally* suited to
solve the interoperability problem.
Today's XML is part of the problem (! not of the optimum solution
because it allows for so many encoding
variations, which requires
XML processors to
be more complex than inherently necessary.
That is at the core of the suggestion I made yesterday (see
Yet, let all this aside, in my opinion:
your approach seems to be valuable for dealing with today's XML,
and should therefore be analyzed closer by OW
> Jimmy Zhang
> ----- Original Message -----
> From: claus.hirth@xxxxxxxxxxxxxx
> To: Jimmy zhang
Tuesday, August 10, 2004 1:37 PM
Subject: WG: [architecture] Fwd: greeting from XimpleWare
> Dear Jimmy,
> quote from
> "XML is, by design,
human-readable [ ... ]"
> That is not so, quite remarkably.
> XML does not prescribe one,
and only one, standard encoding.
> Therefore any XML Editor or XML
Viewer must deal with eg character
> encoding declarations at
> For URIs, XML requires everything that is non-ASCII to be
encoded ineg UTF-8,
> which is not what I would call human-readable.
> See http://www.w3c.org/TR/xmlbase/#escaping
> So really, XML is designed to be completely
> * transferable through every network on the market,
storeable on any storage device on the market,
> but it is not designed
to be completely following the 'view source principle',
> although XML
in most practical cases does come close to this principle...
> The following are the conclusions to draw from the need
> * readable source 'view the source'
> * efficient
marshaling for network and storage transfer:
> (1) Define a
standard 'view the source' form for 'XML';
> eg: require
it to be encoded as UCS-4,
> because that is the only
possible realistic choice.
> Consequence: you
can't 'view the source' if your editor can't
all the characters from UCS-4.
> (2) Compile the 'view the
source' form to a networkable form of XML
> whenever you
save the source from your editor.
> A network byte order
binary XML representation would be one
> Consequence: a standardized
and portable compiler must be made
> available in a FOSS
> (3) Require XML processors to understand
both the binary standard form,
> and the 'view the
source' form, of 'XML'.
> Reason: That let's the
user choose whether he wants to 'view the source'
whether he wants optimum marshaling performance.
Note: By this we also require any XML-View-The-Source-Editor to be
> able to read and display 'network byte order binary
XML' as if it
> were a 'UCS-4-encoded XML'.
> (4) Encourage the transitional support for the current alternative
> of XML such as UTF-8, UTF-16 in XML
processors to support existing
> 'legacy-XML' documents
> I would be interested to hear your
opinions on this. I'd be especially
> interested, and grateful, if you
can point out any flaws that may have
> slipped in.
> Kind regards
> Member of the ObjectWeb
> ----- Forwarded by Claus 2003-05
Hirth/eMaert on 10.08.2004 21:50 -----
> Francois Letellier
<francois.letellier@xxxxxxxxxxxxx> schrieb am 10.
> > Hi all,
> > FYI:
XimpleWare is currently considering joining OW and maybe submitting
> their project, VTD-XML, as an OW project.
> > The email below
explains it all...
> > - Francois
> > >From: "Jimmy zhang"
> > >To:
> > >Subject: greeting
> > >Date: Mon, 9 Aug 2004 13:31:16 -0700
> > >
> > >Hi, Francois,
> > > How are you? Hope all is well.
> > > It was nice talking with you last week in Linux
> > >I am just glad to know that ObjectWeb is offering
> > >world such a great product for free.
> > > We (ximpleware) recently released an open
> > >software called VTD-XML on sourceforge
>(http://vtd-xml.sf.net). The goal is simple: we want to
>make XML Web services applications scale. The
> > >problem
with current generation XML processing
> > >technology is it will
suck up to 90% of CPU cycles.
> > >There has been a lot of
interesting development in
> > >W3C over the subject of binary
XML. Our position
> > >paper is available at
> > >which gives a pretty
good overview of the technology.
> > >
> > > We
are very interested in learning more on how
> > >We can partner
with Object web to deliver move
> > >the XML web services
initiative forward. Could you
> > >suggest procedures or contacts
> > >I appreciate your suggestion of any
> > >
> > >Best regards,
> > >Jimmy
> > >===========
> > --
> > You receive this message as a
subscriber of the
> > architecture@xxxxxxxxxxxxx mailing
> > To unsubscribe:
> > For general help:
> > ObjectWeb mailing lists
service home page: