Lists Home |
Date Index |
- From: Len Bullard <firstname.lastname@example.org>
- To: David Megginson <email@example.com>
- Date: Wed, 03 Nov 1999 21:31:26 -0600
David Megginson wrote:
> (or whatever suits). Really -- just give us a Namespace, and we'll
> do stuff you barely dare to dream about. That way, they can work on
> XHTML itself, modules, and all that at leisure.
Well said. But the spec is back for work, so, selah.
Geekery... I've been reading Neil Maden's papers on OLAP
and multi-dimensional databases for fun.
Why isn't more of the list focus integrating XML for the
client into the analytical systems so the closed loop from the
document dbs to the decision systems is cohesive, fast, and
easier to build than hypercubes. Hypercubes are morph
based names in a slice and dice API. Separate facts/measure
tables (numerical) from dimensions. Isn't a star-based
named schema and relating XML schemas in the namespace
of a metaName set the same thing?
I don't know... fun to consider. Tumblers in the namespace..
The problem of applying schemas is applying them without
the idea of dynamically modifying them so they will pivot,
drill, mine, what have you. The document structure,
if apriori, the schema names, is the range of the
querying space. To aggregate, names must aggregate.
If that is definitional, authoritative, schemas must
be dynamic. Otherwise, they are (neil maden) "time volatile".
Isn't a schema the set of names available to
query in the space, apriori? To me, that is
the main value. The dropdown list.
My task tonight is to map two
languages, both nodal and field, element and attribute.
To do this, I have to abstract out the node names
from the namespace of both languages and determine
the state of the map (language name pairs or outermost
nodes). Do I need a higher level set of names?
yeah... the names of the document parts. legally,
that is the last level of name binding. the document.
The dropdown list. Authoring is the user interface.
That namespace is the legal definition.
The importance of document systems namespaces
is the kind of information traditionally kept in them.
The habit of the culture is to put the information for
the humans in them, and that is precisely the information
one needs to create dimensional data because it describes
how the humans think they use it. In legal systems based
on records of authority, it is the text references that
bear the responsibility that node names carry in namespaces:
A DTD is a hedge on entropy. Even if the rule is
volatile, if applied, the value of the referent
becomes persistent. Persistence is enough to
control the rate of change of the definitions
and their affects on the objects they govern.
A good analytical engine should let you query that
by simple means. Navigate topical
schemas or use the morphology of the
namespace to store the dimensions. Manipulate it,
and let the indexing magic work on the facts. Intersections
are facts. OLAP. m-space.
Something else. X3D ends up putting in externProtos and
Protos so the language is at least, extensible by declarative
aggregation. I suggest the markup community adopt similar
means. We must have it for the 3D graphics and it is
in the abstract set, so it has to be provided. If the idea
is useful and generalizable, go for it.
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 unsubscribe, 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)