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] constructive (was RE: [xml-dev] Markup perspective not c

[ Lists Home | Date Index | Thread Index ]

Hi Simon

Simon said:
I'm not sure why creating XML "created the situation".  Before XML, 
developers had to think about how to exchange and store their
information, 
and after XML, developers still have to think about how to exchange and 
store their information.

Didier replies:
Yes they used RPC and what made RPC useful is that the impedance
mismatch between the language natural construct and the problem
namespace is minimized. The problem RPCs encountered was that there
where common ground (CORBA vs. DCOM). As a Pro for RPC is the
recognition that productivity has to be improved or maintained. This is
why, an RPC resolver or marshaller was automatically produced. The con
was that since the RPCs where developed in times when statically typed
languages where common usage, dynamic data structure was out of
question. What made XML appealing for developers is that capability for
XML to be more flexible and allows dynamic definition of hierarchies.
The con for developers is the lack of sophistication of the tools since
they had to back to the 50s (and probably more than that) and had to
parse the document in order to do something with it. A better solution
would be that the parsing is performed automatically and that the
document's content is accessible both at the syntaxic and semantic
level. The current state of the art is that only the syntax is available
through the DOM. There is still more overhead than a simple RPC. So, the
conclusion is simple enough, developers are taking the more
sophisticated tools. It is like computer users. I still remember people
saying that what we where showing them at Xerox PARC was not doing more
than mainframe terminals. There where right, it was not doing more it
was simply making the user's life more comfortable  and a system more
easy to use. Guess what people selected the mainframe terminal or the
Xerox PARC way of doing things.

If we where thinking to address their needs and provide good tool (I
mean something more sophisticated than parsers) then we would probably
get a positive response. I am wondering if the community is not like the
guys who where telling me that the mainframe terminal where doing the
same thing as my Xerox dorado station.

Simon said:
The only thing that's changed is a common syntax (now markup) for some
of 
that information.  I don't see how that creates a responsibility for
markup 
to do the rest of a job that properly belong with developers close to
the 
specific tasks that need to be solved.

Didier replies:
Yes but the tools to manipulate the document content or the information
contained in the documents are very poor. A parser is not what we can
call "state of the art". It is only the first step toward more
sophisticated tools.

Simon said:
Perhaps in the enthusiasm about solving one problem (syntax) some folks 
thought that they weren't going to have to work anymore, but I don't
think 
that's a problem for XML.  Instead, by attempting to solve all these 
developer problems, something you apparently want to continue doing,
we've 
added all kinds of new problems to XML (and the W3C's use of "XML" in
spec 
names adds to the perception that XML itself has the problems.)

Didier replies:
No I am not attempting to solve all developers problems just a subset.
And I guess you are right when you say that folks where thinking that
they finally got the magic wand. This was part of the irrational
exuberance, at lot of people lost their common sense for some times :-)
My point is, instead of following the RPC path, if we where:
a) offering tools allowing access to the syntaxic and semantic level of
a document. We created element and attribute objects, why not objects
having the element's name. Just examine with attention the rendering
languages and you'll notice that most of them are defining hierarchies
of objects and these object have properties. We are talking here of
visual or aural objects and these objects are not called elements but
lines, rectangles, circles, forms, etc... So, if we created elements and
attribute objects mostly for statically typed language why not create
semantic objects for dynamically type languages like java or ECMAscript.
Gee we did it back in the 70s with smalltalk. Are we getting more brain
damage as time passes?

Simon said:
It's time to stop solving developers' problems generically, and let them

solve the problems themselves building from only a basic syntactic 
framework - if and only if the framework is appropriate to their 
problem.  XML is not a magic wonder-glue for programming.

Didier replies:
This is what they do using XML as a framework to define a marshalling
language. They are using what they know because they have no better
offer. They looked at XML, saw a meta language that allows to create
domain languages and they created a domain language: a marshalling
language. If Jon and al. are having some success with their proposal of
business documents like invoice, catalogs, etc... They will need the
proper tools to extract the semantic information to help the developers
resolve the problem not create new ones by asking them more work than
they have to do today. You know, some centuries ago the request from the
people for more bred got as response from the queen "if they have no
bred, they just have to eat cookies". Guess what happened :-) As the
guys who said that our Xerox Dorado was doing the same thing as the
mainframe terminals learned, people will seek the solutions that answer
their needs.

Cheers
Didier PH Martin






 

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

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