[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Didier's labs report.
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@n... 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@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/ ***************************************************************************
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|