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

RE: XML Schemas: even more complex than Java

  • From: "Bullard, Claude L (Len)" <clbullar@i...>
  • To: Arnaud Sahuguet <sahuguet@g...>,XML-DEV <xml-dev@l...>
  • Date: Fri, 27 Oct 2000 12:02:30 -0500

java dom schemas
I don't know motivations here.  I can comment 
on some history.  There have been several efforts 
during which markup declarations have been extended 
to provide OOP features.  The US Navy MID effort 
defined an entire C++ like application vocabulary 
for that.  It was done because the Navy wanted 
full interoperability among IETMs and data portability 
among the vendors.  Dr Goldfarb and Yuri Rubinsky were 
adamant that such a thing should not go forward 
because programming in SGML just was not done 
(there are issues of working group overlaps, etc). 
Other SGML luminaries, notably Steve deRose commented 
that exchanging one bracket for another wasn't such a 
good idea if no new functionality was also provided. 
True, but if you want one syntax for the whole file, 
one parse, etc, it made sense.

A few members of the audience at the 95/96 Hytime conference 
commented after Neill Kipp's presentation of the language 
that they didn't need yetAnotherC++.  Oddly, it dropped 
a lot of C++ and made assumptions Java and VB proved: 
virtual machines and interpreted languages for objects 
can be wonderful things.  Nodes is nodes.

The HTMLers saw it as a potential competitor to HTML 
and it was.  Just a lot more powerful and it was a 
conforming SGML application language.  Putting HTTP 
under it would have been the next step but at that 
time, no one in the IETM world needed it and the 
customer rules on that kind of requirement.  Still, 
that would have been easy.

So we redid the design and came up with the infoContainers 
that one would recognize as very similar to what is now WAP 
(framed) and included a scripting tag set. 

Some say running code rules.  It was implemented, 
four times by three different implementation groups, 
shown to work like gangbusters, 
provided sequencing, and could perfectly mimic a windowing 
environment right down to modal and modeless dialogs.  
Again, the HTMLers saw a competitor, folks like 
Eliot Kimber said "I'd do that differently" and Rubinsky 
told me privately "No one will use this.  Our business 
is now HTML."  As the SGML vendors closed ranks against 
it in concert with HTMLers, the funding dried up.  Oh well.  
Thus died one HyTime based effort that worked and worked well.

Rough consensus is, well, rough politics.

That was 1995/96.   Note that as HTML added scripting, 
they also carefully avoided tags and JavaScript emerged as 
a C-like analogue with objects all inside comments 
to avoid syntax collisions.

Then came XML.

Since then I can count numerous efforts to use XML 
to define GUIs, languages, scripts, and so forth. 
There is what I used to call the pine tree effect of 
markup:  healthy tree but nothing else grows around it. 

Many people complained how inadequate DTDs are 
for data modeling.  Ok, the syntax issues of stuffing 
a BNF-like syntax into a file with the markup was solved 
and DTDs became hard to send with instances, but wait, 
schemas aren't.  So we went from well-formed instances 
to schema+instance in the same syntax.  Moreorless what 
SGML does.
 
Then folks wanted data structures above the level of 
strings.  Now structures are defined and available that 
match most or all of what a relational programmer has. 
This was a very good move although the schema has to 
travel with the instance to achieve portability.

Now people want class-like definitions, so we are back 
to circa 1995 with a declarative form that just missed 
the MID objective in that there aren't any methods and 
the only people objecting seem to feel as others felt 
in 95 that such a thing is competitive with existing 
languages.  

Should schemas have implementation sections?  That might 
fix the semantic problem people complain about.  Yes?

Ok.  Sure they are starting to compete with Java.  Get 
used to it.  Pine tree forests have no flowers beneath the needles.

How do you stop feature creep?  Turn off the requirements 
projector.

Len 
http://www.mp3.com/LenBullard

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


From: Arnaud Sahuguet [mailto:sahuguet@g...]

If you read carefully the latest XML-Schema spec,
you will notice that some newly added features look
suspiciously like features borrowed from Java-like programming
languages.

Sometimes, I really wonder if some members of the working group were not
pushing
for these features because they had a working implementation of XML
Schemas that was using them internally.

PURCHASE STYLUS STUDIO ONLINE TODAY!

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.
Email
First Name
Last Name
Company
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.