an unfilled need

[Len Bullard]

Sean Mc Grath wrote:
> 
> But this only becomes an issue whenever there is
> a need to interface between disparate systems. Of course you
> need standards at that point -- be they APIs or Data Notations.

Good Sean.  The standard is either:

1.  Needed because a minimal contract must be in place 
to make an exchange (often a validatible one)

2.  It is already done, so convenient.  Skip the reinvention 
of the wheel.  Most of the hard computer science research 
was done by 1969.  :-)

> Here is the point I was trying to make. If the algorithm to
> manipulate the data is downloaded *with* the data,
> then the browser meeds no apriori knowledge about
> the semantics of the data other than "Oh, here comes a package
> of stuff that has an algorithm part and a data structure part.
> Execute the algorithm part and hand it the data part to work
> with".

Yes.  Encapsulate where possible and USEFUL.
 
> Moreover, as an application developer I can do what I like
> with the package of data. I can attach any semantics I like
> to it. JavaScript is a case in point. Leaving aside any
> dislike for the language or the data model exposed to the
> language, it illustrates the "arbitrary semantics" point
> well.

Yes.  You have a means to define and post the semantics, so 
you did.  Like or dislike scripting, it enables you 
to move the semantics.  Declarative means aren't always 
sufficient.  It becomes markup's blind spot because people 
adopt markup religiously.  The originators never questioned 
the use of procedural means; they stayed silent because they 
did not consider these their's to prescribe.  (OTOH, using a 
namespace or face it, a URI/URL to point out where the 
semantics and other definitional resources are is not a 
dumb idea, but apparently, not easy to achieve if one is 
committed to minimal victories.)
 
> Isogen did not have to wait for the W3C or Microsoft
> on Netscape or some committee to quabble endlessly over
> the markup language necessary to encode the semantics
> of a collapsible toc.

Nor did Microsoft wait.  Collapsible TOC code is everywhere.  
It recognizes the truth about dynamic presentation:  it 
is procedural.  So the question is only, will it run in 
this or that framework of objects?
 
> >And anyhow, why bother with XML then?
> 
> XML gives me a beautifully simply, open systems, way
> of expressing a hierarchical data structure. Why would
> I throw that away?

It gives you syntax unification and all the support 
provided by frameworks that do that.  The only question 
is, can your algorithms be supported by the local objects?  
For that reason, for many apps, helper apps make a lot of 
sense. 

When people ask me why XML hasn't been adopted faster, I 
tell them that most of the things people need to do right 
now can be done COTS.  When they ask me why they should 
do XML, I tell them because anything taken off a shelf has a 
shelf life except information.

len



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)