xml-dev - Re: XHTML 1.0 returned to HTML WG

[Len Bullard <cbullard@hiwaay.net>]

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: 
referent stabilization.

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.

len


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