Lists Home |
Date Index |
- From: Len Bullard <email@example.com>
- To: "Steven R. Newcomb" <firstname.lastname@example.org>
- Date: Mon, 22 Nov 1999 18:49:58 -0600
Steven R. Newcomb wrote:
> My main point is, I think, also yours: it causes unnecessary grief to
> assume that the interchange structure of an XML resource needs to be
> the same as, or even correspond to, the API to the information that
> the XML resource carries.
That is true. An API is designed to be an interface to information;
not the other way around. But define the lexical types, freeze the
sets (probably not a good idea, IMO), declare namespaces and schemas,
you get a good enough structure to manage information for many kinds
of easily proven good bits of information for reasonable transactions
among interfaces, the system boundaries.
Define what goodness in information is: coherence.
Declare a lexicon, let namespace families aggregate by
frequency and control referents (W)), that when valid,
do not degrade the value of W which may be modeled as phasing.
Coherence is the capacity of the namespace family to carry
information with the least noise through the most cycles.
Given a set of XML application languages (vocabularies), what element
names are being shared and do these conflict semantically? How is this
Markup needs semantics. The information at some level, systemically,
is bound to the machine.
So we have: (forgiveSimplification)
o Event Parsing: SAX, event-oriented, tag-stacker, system driven by
o Object-oriented: DOM, instantiate the property set as a tree of
objects with interfaces
That works fine. Why not? The purpose of structured information is
to bind it and share it among cooperative entities where cooperation
is defined as the transactions among defined boundaries, cooperation
by the framework of interfaces shared. The Browser doesn't care.
It see this all as services. That's fine. Good design.
> I mentioned the DOM only as an *example* of ready-to-run objects; I
> did not intend to say that the DOM is useful for every purpose.
Right. DOM is good when you need an object in memory to talk to.
SAX is good when you need an object in memory to talk to you.
> Ready-to-run objects (including your indexes) are ready-to-run
> objects, regardless of the process by which they were created.
But not by the definition of the interface. To use the definition,
at least at the IDL, you need a schematic representation of the
How do I know they are <readyToRun>? Where in the markup do I find this
<readyToRun> tag? (ok... yep, messages in markup, right?) DNA?
> Ready-to-run objects (whatever one may call them, and regardless of
> how they are implemented) are manufactured by all applications of XML,
> not just by some of them.
Sure. That's the beauty of it. Pick any good object, relational,
stringMachine system and it still works. The hard problem is
when the machines are through with it, does it still mean the
same thing? Can we prove it?
Does that matter if practice reveals we don't always have to
be able to prove it? We have to be able to prove it often
enough and in enough formats that the maps in the right
places don't become incoherent.
I was reading the Cocoon papers and the notion of "hot spots"
is perfect because the optimization is by the frequency of
use. Good metaphor. Some may want to look up some DARPA work
from the early eighties (DICE project) on the application
of the model of simulated annealing.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)