Lists Home |
Date Index |
- From: Len Bullard <firstname.lastname@example.org>
- To: Sean Mc Grath <email@example.com>
- Date: Thu, 09 Sep 1999 12:22:09 -0500
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
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
> dislike for the language or the data model exposed to the
> language, it illustrates the "arbitrary semantics" point
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
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.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)