OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: RE: [xml-dev] Painful USA Today article (was RE: [xml-dev] AN N: R E

[ Lists Home | Date Index | Thread Index ]

That's fine as long as you have a plan to cope with 
unknowns (what you don't know) and unknown unknowns 
(what you don't know you don't know).  That plan may 
be anything from start over to fail.  "Fear is the 
mindkiller" as Herbert wrote.  Still, if you stick 
to a small problem everyone has and solve that, you 
have a least made a lot of people more productive.
 
If you try to solve everybody's problems with one 
solution, you are likely to have mostly dissatisfaction. 
But until you can think through precisely what the 
problem is, this advice won't get you far.  XML 
could be simplified because SGML was already done. 
Building a simple thing first to solve a ubiquitous 
problem is quite difficult.  You have to be very 
precise about the problem.

XML is what it is (1.0) because that 
can solve one problem shared by many people:  a 
syntax for transporting data objects better than 
delimited ASCII.  Once past that, the numbers of 
problems solved effectively appear to diminish proportional 
to the number attempted by any one application.  This 
is one reason to get nervous about those who want 
to consider the syntax merely a serialization of the 
InfoSet-spec'd properties.  It looks reasonable but 
notice the problem definition just changed.

Try this.  Make a list of all of the XML applications 
and XML systems you use.  Next to that, put a short 
but precise description of the problem to which it 
is applied.  The first problem is working out what 
is an XML application vs an XML system.  Note how 
often you are depending on concepts such as the 
InfoSet vs how often it is just syntax and known 
names and value spaces.   When is it useful to 
have a schema?   We think we understand all that 
and some do, but that was the kind of thinking that 
went into simplifying SGML.

I wanted to get rid of parameter entities, myself. 
Some said they couldn't maintain complex DTDs without 
them.  I said, maybe complex DTDs are the problem 
that preserves the problem.
 
Point of view....

len

From: Rex Brooks [mailto:rexb@starbourne.com]

Is there something inherently wrong with just proceeding to start 
small in scope and do what you can do well as you can as long as it 
allows for further development and doesn't box you into a corner or 
add so much computational overhead that it becomes unuseable?




 

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

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