xml-dev - Didier's labs report.

["Didier PH Martin" <martind@netfolder.com>]

Hi

Here is a report from my current work on permanent information sets and the
incidence on the DOM.

Definition: What's a permanent information set?
-----------------------------------------------
A permanent information set is like a special kind object data base or a
particular kind of hierarchical data base. It contains a permanent tree
structure of nodes and these nodes have the types or inherit from the types
explicitly mentioned in the DOM recommendations. By type inheritance, I mean
here that an element node could be also - in addition to be an element
node - be of an other type like, for instance, to be also an instance of an
"invoice" type. This implies that the node _isa_ element type and _isa_
invoice type. Thus, the basic element type interface is augmented with new
methods and properties. The object can then be accessed either as an element
or as an invoice.

Use case:
---------
A directory service is a tree structure where each node is associated to a
property set. This structure could be easily modeled with XML which also
possess a hierarchical structure. Or it could be modeled with other models
like, for instance, the RDF model. I remains that a directory service can
also be mapped to an XML document type. When this document type structure is
kept in a permanent information set, we have a live directory service. This
directory service can be accessed with standard APIs like LDAP or perceived
as a document and then accessed with the DOM interface. This latter
interface can be used to render the directory structure or part of it with a
style sheet. The structure could also be used to aggregate content. If the
directory service is interfaced with a permanent information set, then its
content can be transformed into an other structure or can be styled for
rendition. These last processes can occurs without parsing of a text
document since the permanent information set is already accessible through
the DOM. Therefore, any operation on the permanent information set is
obviously faster than when a parsing is required. Also, the permanent
information set can optimize memory access so that large collections could
be processed and that all the advantages of the DOM be kept.

An other use case is to provide a hiearchical interface to a relational data
base and a node set be the result of an SQL query. However, from the
outside, any client perceive the tree structure without knowing that when an
element is requested on a specific part, a dynamic SQL request is made. This
allows to aggregate collection of resources in a tree structure or to
perceive a collection of resources as a document that can be processed with
tools like XSLT, DSSSL or any tools using the DOM as a data source.

Problem:
--------
To obtain a node or node-set from the permanent information set for
processing. The first client for this kind of query is obviously XSLT with
requires node sets from an information set for template processing. Thus,
the problem here is to have a standard way for an XSLT processor to request
a node set from a permanent information set.

Proposed solution:
------------------
A new member added to the node interface. because any DOM entity inherit
form the DOM interface and therefore any object _isa_ node, the query
feature becomes available from any object obtained from the permanent
information set. This  feature prevent to request a new object just to do a
query since a query can be done from any object obtained from the permanent
information set.

The proposed function to be added to the node interface is:

node-set SelectNodes(queryType, Expression)

Where the returned value is a node set. The node set can be either a
collection or a singleton but the type is always node-set.
The parameters are:
queryType which indicates the query type. For instance, if the query type is
"XPath" then the expression is an XPath expression. If the query type is "My
own query type" then the query expression is one recognized by the engine.
However, in any cases the function remains the same. It is the engine
responsibility to recognize the query type and process it. If  a query type
is unknown to the engine, then this latter throw an exception.
Such function allows new query languages to be added without multiplying the
entities ad thus, Occam can rest in peace with a huge smile on his face :-)
A secondary advantage is that by integrating this member in the DOM and
having the DOM interface defined in CORBA and DCOM (no need to define for
Java since the Java JDK includes a CORBA to java mapping). I'l have to
double check but I think that the XPCOM interface definition is the same as
CORBA. Because ECMA is a special case and because no CORBA to ECMA script is
defined yet, an ECMA script interface is to be defined too.

Note: to define a DCOM interface has the advantage that proprietary
extensions or experiment extensions can inherit from the standard one. For
instance, the actual Microsoft interface definition poses a problem since
extension members and standard DOM members are present in the same
interface. Instead, the extension interface should inherit from the standard
one. So, as a good practice, the DCOM interface should be defined for the
standard DOM and any extension defined in an interface that inherits from
the standard one. This is not the case actually for the Microsoft DOM. So,
This is why I see that interfaces has to be defined for DCOM (with a
notation as possible near to the OSF RPC standard), for CORBA and finally
for ECMA script. Java and Visual basic mapping can be defined respectively
from the CORBA and DCOM interfaces. Remains to be defined: Python and PERL
interfaces.

Any feedback appreciated (as long as it is practical and constructive ;-)

Cheers
Didier PH Martin
----------------------------------------------
Email: martind@netfolder.com
Conferences: XML Europe (http://www.gca.org)
Book: XML Professional (http://www.wrox.com)
column: Style Matters (http://www.xml.com)
Products: http://www.netfolder.com


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************