OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: need for defining standard APIs for xml storage

[ Lists Home | Date Index | Thread Index ]
  • From: "Didier PH Martin" <martind@netfolder.com>
  • To: "KenNorth" <KenNorth@email.msn.com>, <xml-dev@xml.org>
  • Date: Tue, 4 Apr 2000 07:58:22 -0400

Hi Ken,

[post about the SelectNodes function...]

I didn't found the example you are referring to but if I take the example
Dongwood gave in:
"If your SelectNodes function does some, it is close to the notion of
indexing.
Otherwise, it seems inevitable to search the whole document space
against the query "find the SPEECH having 'sword, love'" even with
SelectNodes function (I mean SelectNodes function should do at
run time)."

Then I would:
a) tell the information set engine what kind of query language I am using.
So here, let's say that the query language is named "Dongwood". The query
type is expressed as a string
b) The query expression itself expressed as a string so that have "find the
SPEECH having 'sword, love'"

Therefore the SelectNodes member would return a node-set when a call like
below is made.

Result = Object.SelectNodes("Dongwood", "find the SPEECH having 'sword,
love'");

The information set engine returns a node-set which may contain either a
collection or a singleton.

Now, let's say that the engine retrieved documents stored on the web and
accessible only through HTTP. Then, the client is not aware of this fact and
the "wrapper" function providing a "facade" to the information set that
wraps among other things, the web. The engine used to link to these document
located anywhere on the planet is an indexing engine. So, the documents
returned are each enclosed in an element and each document being an
element's data content. The document collection is then returned in the form
of document nodes or in the form of an interface derived from the document
node interface. So, in fact, we didn't created an XML element per se but
more a document node to contain the data content. If the document is semi or
fully structured then a more complete node-set is returned for each
collection's member of the returned a node-set. I mean here that each member
of the node-set collection is itself a node-set if the document or the
fragment each node represents is semi or fully structured.

An other case maybe where, in the same information set we do a query to a
sql engine. In that case we have:

result = object.SelectNodes("sql", "from my-gizmo-table select chips,
motherboards, components where motherboard='gizmo land'
")

The returned node-set is the result of the sql query. This happened even if
the information set does not contain the data but uses a sql server located
in North pole  (the Santa Claus DB) :-).

An other case maybe where the query is done on a set of semi or fully
structured documents. Such as:

result = object.SelectNodes("xpath", "/doc[title='A gizmo on each
desktop']")

The query is simply an xpath query on (a) either a document located in the
physical boundaries of the information set or (b) a document internally
referred to be located in the Santa Claus library and this latter accessible
though WebDAV. Then, even if the function client perceive the information
set as an integrated structure, the information set engine, does an internal
WebDAV request to check out the XML document, then convert the requested
fragment into a node-set and return this latter to the client.

In several of the use cases mentioned, the information set wasn't the data
container but more a wrapper to access the data. In case 2, the designer of
the information set engine decided to percolate the sql data model up to the
user. However, the information set provider may have chosen to store the sql
request in an internal "node" and present to the user a simple hierarchy of
nodes. When a request is done is that "node", then the sql request is made,
and the data returned in the form of a node-set. So, in that case an "xpath"
query result is, intenally, a sql query and some node processing and
externally, a node-set returned as the product of the function call. We did
an Xpath call to a hierarchy, no navigation from node to node was made
internally but more a sql request to the Santa Claus DB and then a node-set
produced. Even more, the information set provided may have followed the good
lesson we learned from relational DB and have an internal query optimizer
able to parallize request to obtain the data and deal with network
latencies.

There are several variations possible on an information set engine itself
like:
a) a transient information set - like the ones found in browsers or XSLT
engines. The information set exist only for a certain moment and it
disappear at the end of the processing
b) a permanent information set - a bit like a hierarchical data base but
could be a wrapper to data sources. The existence of the information set
transcends the limited existence of its content usage .

The information set present a common interface to data sources even if:
a) the data is contained in the information set engine boundaries
b) the data is not contained within the information set engine boundaries.
In this latter case, the information set engine act as a wrapper providing a
common "facade" to heterogeneous data sources

Finally the information set engine may present:
a) a single name space (i.e. a hierarchy of nodes)
b) multiplicity of name space (like supporting LDAP, SQL, Xpath, etc. kind
of queries)
c) single data model (i.e. like the DOM data model)
d) multiple data model (like a custom data model, the DOM, the linkage
model, etc...)

There is also more to say about this topic but let's take a chunk at a time.
And have some time to work on its implementation too ;-)

cheers
Didier PH Martin
----------------------------------------------
Email: martind@netfolder.com
Conferences: Web Chicago(http://www.mfweb.com)
             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/
***************************************************************************




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS