[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Simplification and Composability (RE: SOAP Message Transmissio

  • To: "'Simon St.Laurent'" <simonstl@s...>, xml-dev@l...
  • Subject: Simplification and Composability (RE: SOAP Message Transmission Optimization Mechanism)
  • From: "Bullard, Claude L (Len)" <clbullar@i...>
  • Date: Tue, 22 Jul 2003 12:20:24 -0500

oster stylus
It helps if those doing the simplification are roughly
the same people who did the original.  In the case of 
XML, that was 90% true.

One could argue that simplification of complex systems 
is normally achieved by encapsulating a feature into 
a different component or layer and decoupling it  
via an interface.  DTDs were made optional and that 
made sense for networked systems.  But the problems 
of augmentation and the requirements for validation never 
disappeared.   The syntax problem (DTDs in a different 
syntax) was factoring because in practice, it wasn't 
a problem.  It simplified the parse.  Was that a large 
gain?  Opinions vary but it did open up the technology 
to competing solutions there, and one might say it 
simplified the technology but made the environment 
more complex (how many validation types does one want 
to support).

Namespaces seem to complexify everything they touch. 
Because SGML did not deal with these except in subdocuments 
where the complexification was rough encapsulation, there 
was no prior experience except by analogy to other 
languages and the Oster system.  

If one accepts the assertion that XML itself 
is only syntax, then namespaces work reasonably well. 
If one attempts to use them with any other semantic, 
results vary.

You have no doubt noted Sandro Hawke's thread on the TAG 
concerning modularity and composable languages.  Permathread 
#3, (How Does XML Support Composable Languages) 
is on the schedule again.

I wonder who will be the first to resurrect Brad Cox and 
Software ICs.  Now that is a golden oldie, but closer 
to the solution than most.  It leads to C#, Java and UML 
and away from declarative data objects.


From: Simon St.Laurent [mailto:simonstl@s...]

clbullar@i... (Bullard, Claude L (Len)) writes:

>At least it is easy to see now how SGML became as 
>complex as it did over time.  What doesn't get 
>put into XML shows up in the applications.  It 
>will be fun as some of us get closer to retirement 
>and watch the next generation of "we can do this 
>simpler and better".
>Cars and jets never get simpler overall.  Why 
>do people believe software should?

In general, I don't expect it should.  In this case, I think it's funny,
because a group threw away all those features, claiming they were too
obscure, and then reinvented them in a form that seems even more

Reinventing the wheel is fine, as long as you come up with a better
wheel.  I think XML 1.0 (and perhaps XSLT 1.0) set a standard for
improving wheels by simplification that hasn't been matched since.


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.