You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xindice-dev@xml.apache.org by Murray Altheim <mu...@sun.com> on 2002/01/22 21:51:21 UTC
XNode API Proposal
This message describes the XNode, an API for use with Xindice that I've
sent on to Tom and Kimbro for review. This is considered a proposal, a
donation to the Apache project's Xindice code base. I'm interested in
hearing feedback, and if it's generally positive, the API would be
donated as part of Xindice. Sun will be releasing a UDDI registry project
soon that includes an implementation of this API. If accepted as part of
Xindice it'll be under an Apache license, if not, Sun will probably
maintain copyright of it. Since I'm leaving the company next week to
return to school I'm hoping the Xindice community accepts this donation,
as I'd like to see it become a part of Xindice (I'm the author).
I'm hoping to post online the entire javadoc of the API sometime
soon. I'd send it to the list (a 32K zip), but I know how people
feel about attachments on listservers, and I'm not sure it'd get
through anyway. So below is a brief description in lieu of the more
extensive documentation.
------------------------------------------------------------------------
Description
Since Xindice has no general method for associating metadata with each
"record" in the database, XNode was developed for this purpose. XNode
is a very simple API, only five files (including an Exception class).
An XNode is an object acting as a container for XML content by providing
an envelope element and some basic metadata attributes such as a node ID
(nid), a timestamp, etc. If you're familiar with SOAP, it'll seem similar.
An instance of such markup (wrapping an XHTML document) might appear as:
<xnode:Envelope xmlns:xnode="http://www.apache.org/xnode/1.0/"
xnode:id="n3892">
<xnode:Header
xnode:created="2001-10-22T18:33:56"
xnode:modified="2001-10-24T09:11:37" />
<xnode:Body>
<html xmlns="http://www.w3.org/1999/xhtml">
[document content]
</html>
</xnode:Body>
</xnode:Envelope>
Substituting "SOAP-ENV" for "xnode", this is notably similar to a
*very* simplified SOAP (which for having "Simple" in its title
isn't in the end all that simple). The above code is how an XNode
is stored in Xindice, such that upon extraction the XNode object
can be reconstituted. The XNode <xnode:Header> element is designed
to be extended for other purposes, though 'created' and 'modified'
should be supported.
----------------------
Classes and Interfaces
XNode abstract class:
the XNode object, a wrapper for XML content.
XNodeException class:
extends Exception for exceptions thrown in XNode processing.
XNodeState final class:
defines a fixed set of enumerated types as processing states.
XNodeFactory interface:
defines an interface for a factory for creating XNode objects.
XNodeStore interface:
defines an interface for a processor for connecting and
disconnecting from a Xindice server as well as common
Collection and Node manipulations (create, get, delete, etc.)
----
Comments welcome.
Murray
...........................................................................
Murray Altheim <mailto:murray.altheim@sun.com>
XML Technology Center, Java and XML Software
Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., Menlo Park, CA 94025
Corporations do not have human rights, despite the
altogether too-human opinions of the US Supreme Court.
Re: turning off xmlns:src, src:col, src:key attributes
Posted by Michael S Huang <mh...@yahoo.com>.
Thank you for reply. Could you please give me a hint as to which files
would be likely affected.
Thank you !!
Michael
----- Original Message -----
From: "Kimbro Staken" <ks...@dbxmlgroup.com>
To: <xi...@xml.apache.org>
Sent: Tuesday, January 29, 2002 3:47 AM
Subject: Re: turning off xmlns:src, src:col, src:key attributes
>
> On Thursday, January 24, 2002, at 05:38 PM, Michael S Huang wrote:
>
> > Hello -
> >
> > I searched through Developer's Guide but could not find answer. Perhaps
> > I
> > missed it.
> >
> > Could someone point out whether it is possible to turn off the insertion
> > of
> > "xmlns:src", "src:col", and "src:key" attributes in the Resources coming
> > back from XPath queries (eg, through the Configurable interface).
> >
>
> There isn't any way to do this right now, there really should be though.
> Should be simple to add if you want to take a crack at it.
>
> > Thank you, Michael
> >
> >
> >
> Kimbro Staken
> XML Database Software, Consulting and Writing
> http://www.xmldatabases.org/
Re: turning off xmlns:src, src:col, src:key attributes
Posted by Kimbro Staken <ks...@dbxmlgroup.com>.
On Thursday, January 24, 2002, at 05:38 PM, Michael S Huang wrote:
> Hello -
>
> I searched through Developer's Guide but could not find answer. Perhaps
> I
> missed it.
>
> Could someone point out whether it is possible to turn off the insertion
> of
> "xmlns:src", "src:col", and "src:key" attributes in the Resources coming
> back from XPath queries (eg, through the Configurable interface).
>
There isn't any way to do this right now, there really should be though.
Should be simple to add if you want to take a crack at it.
> Thank you, Michael
>
>
>
Kimbro Staken
XML Database Software, Consulting and Writing
http://www.xmldatabases.org/
turning off xmlns:src, src:col, src:key attributes
Posted by Michael S Huang <mh...@yahoo.com>.
Hello -
I searched through Developer's Guide but could not find answer. Perhaps I
missed it.
Could someone point out whether it is possible to turn off the insertion of
"xmlns:src", "src:col", and "src:key" attributes in the Resources coming
back from XPath queries (eg, through the Configurable interface).
Thank you, Michael
Re: XNode API Proposal
Posted by Stefano Mazzocchi <st...@apache.org>.
Murray Altheim wrote:
> XNode was designed to be (a) simple, and (b) not require any changes
> whatsoever to Xindice or XML:DB. It's certainly possible to create an
> entire metadata layer/level and add complexity to Xindice (or XML:DB),
> but I felt that the best approach was something that was an add-on
> layer, something that could be ignored if unwanted, not extra baggage.
I wouldn't call the ability to cache a database 'extra baggage' and I
wouldn't personally trust a database which design isn't designed to
include basic metadata.
Sure your XNode proposal is a step in the right direction, but why
should be we shy in going down that road if it makes the system more
useful and better integrated with existing systems?
> It certainly could be used for either application- or database-level
> metadata, depending on how the metadata is designed (ie., XNode can be
> easily extended by adding either attribute or element content to its
> <xnode:Header> element.
>
> I specifically didn't want to reinvent SOAP (which is hardly "simple"
> anymore, with new extensions coming out each month).
Neither did I.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: XNode API Proposal
Posted by Tom Bradford <br...@dbxmlgroup.com>.
On Thursday, January 24, 2002, at 01:17 PM, Kimbro Staken wrote:
> I'm going to be out of town for the rest of the week so I just wanted
> to say I'm +1 for accepting this. We can worry about exactly what we do
> with it later. It isn't something that alters the core functionality of
> anything, it's just an added option that can be ignored if you want.
I'm +1 as well.
--
Tom Bradford - http://www.tbradford.org
Developer - Apache Xindice (Native XML Database) - http://xml.apache.org
Creator - Project Labrador (Web Services Framework) -
http://notdotnet.org
Re: XNode API Proposal
Posted by Kimbro Staken <ks...@dbxmlgroup.com>.
I'm going to be out of town for the rest of the week so I just wanted to
say I'm +1 for accepting this. We can worry about exactly what we do with
it later. It isn't something that alters the core functionality of
anything, it's just an added option that can be ignored if you want.
On Thursday, January 24, 2002, at 12:06 PM, Murray Altheim wrote:
> Stefano Mazzocchi wrote:
>>
>> David BERNARD wrote:
>>
>>> Because metadata is only a point of view : metadata are data.
>>
>> I think David touched the key question: what should XIndice be concerned
>> about?
>>
>> In our recent XIndice wish-list thread, we identified the need for
>> having 'metadata' exposed by the database.
>>
>> I believe there are two kinds of metadata:
>>
>> 1) application level metadata
>> 2) database level metadata
>>
>> an example of the first is 'author' or 'workflow-status'. This doesn't
>> require changes in the DB if fully namespace-aware.
>>
>> examples of the second is 'modified-time', 'lask-accessed-time', 'id'
>> and all sorts of 'automatically-augmented' attributes.
>>
>> For the first class of metadata, I see any reason to expose it at this
>> level: Xindice is a DB engine, not an application provider. It's not its
>> concern to expose this data and as long as namespaced are handled
>> correctly, the application sitting on top has maximum freedom to use the
>> best scheme the want to store metadata.
>
> XNode was designed to be (a) simple, and (b) not require any changes
> whatsoever to Xindice or XML:DB. It's certainly possible to create an
> entire metadata layer/level and add complexity to Xindice (or XML:DB),
> but I felt that the best approach was something that was an add-on
> layer, something that could be ignored if unwanted, not extra baggage.
> It certainly could be used for either application- or database-level
> metadata, depending on how the metadata is designed (ie., XNode can be
> easily extended by adding either attribute or element content to its
> <xnode:Header> element.
>
> I specifically didn't want to reinvent SOAP (which is hardly "simple"
> anymore, with new extensions coming out each month).
>
> Murray
>
> .........................................................................
> ..
> Murray Altheim
> <mailto:murray.altheim@sun.com>
> XML Technology Center, Java and XML Software
> Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., Menlo Park, CA
> 94025
>
> Corporations do not have human rights, despite the
> altogether too-human opinions of the US Supreme Court.
>
>
Kimbro Staken
XML Database Software, Consulting and Writing
http://www.xmldatabases.org/
Re: XNode API Proposal
Posted by Murray Altheim <mu...@sun.com>.
Stefano Mazzocchi wrote:
>
> David BERNARD wrote:
>
> > Because metadata is only a point of view : metadata are data.
>
> I think David touched the key question: what should XIndice be concerned
> about?
>
> In our recent XIndice wish-list thread, we identified the need for
> having 'metadata' exposed by the database.
>
> I believe there are two kinds of metadata:
>
> 1) application level metadata
> 2) database level metadata
>
> an example of the first is 'author' or 'workflow-status'. This doesn't
> require changes in the DB if fully namespace-aware.
>
> examples of the second is 'modified-time', 'lask-accessed-time', 'id'
> and all sorts of 'automatically-augmented' attributes.
>
> For the first class of metadata, I see any reason to expose it at this
> level: Xindice is a DB engine, not an application provider. It's not its
> concern to expose this data and as long as namespaced are handled
> correctly, the application sitting on top has maximum freedom to use the
> best scheme the want to store metadata.
XNode was designed to be (a) simple, and (b) not require any changes
whatsoever to Xindice or XML:DB. It's certainly possible to create an
entire metadata layer/level and add complexity to Xindice (or XML:DB),
but I felt that the best approach was something that was an add-on
layer, something that could be ignored if unwanted, not extra baggage.
It certainly could be used for either application- or database-level
metadata, depending on how the metadata is designed (ie., XNode can be
easily extended by adding either attribute or element content to its
<xnode:Header> element.
I specifically didn't want to reinvent SOAP (which is hardly "simple"
anymore, with new extensions coming out each month).
Murray
...........................................................................
Murray Altheim <mailto:murray.altheim@sun.com>
XML Technology Center, Java and XML Software
Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., Menlo Park, CA 94025
Corporations do not have human rights, despite the
altogether too-human opinions of the US Supreme Court.
Re: XNode API Proposal
Posted by Stefano Mazzocchi <st...@apache.org>.
David BERNARD wrote:
> Because metadata is only a point of view : metadata are data.
I think David touched the key question: what should XIndice be concerned
about?
In our recent XIndice wish-list thread, we identified the need for
having 'metadata' exposed by the database.
I believe there are two kinds of metadata:
1) application level metadata
2) database level metadata
an example of the first is 'author' or 'workflow-status'. This doesn't
require changes in the DB if fully namespace-aware.
examples of the second is 'modified-time', 'lask-accessed-time', 'id'
and all sorts of 'automatically-augmented' attributes.
For the first class of metadata, I see any reason to expose it at this
level: Xindice is a DB engine, not an application provider. It's not its
concern to expose this data and as long as namespaced are handled
correctly, the application sitting on top has maximum freedom to use the
best scheme the want to store metadata.
Another issue is with database-level metadata: there must be a defined
way to obtain this metadata (and modify it, if it makes sense).
IMHO, the XNode API you propose it's not useful in this sense since it
mixes concerns: there is no clear distinction between what is
application level and what is database level.
A possible solution, which require a simple XML:DB API change, is to use
a special namespace (an API-related one, not a container-specific one,
to keep things portable) a for db-related data.
Imagine you have your database as such
<db:database xmlns:db="xml:db api" name="news">
<db:collection name="blah">
<db:node
db:inserted="20020302"
db:last-modified="20020304"
db:event-handler="org.fool.MyEventHandler"
>
<db:metadata xmlns:app="some application">
<app:author>Stefano</app:author>
<app:version>1.0.23</app:version>
<
</db:metadata>
<db:data>
<xhtml xmlns="xhtml">
<body>
<p>blah blah</p>
<db:node db:last-modified="20030303">
<db:data>
<p>blah blah</p>
</db:data>
</db:node>
</body>
</xhtml>
</db:data>
</db:node>
...
</db:collection>
...
</db:database>
[NOTE: this is a *view* of the database, doesn't mean this is to be the
way the database is stored in memory or disk!]
Now, suppose you can ask the XML:DB connector to behave in
'metadata-mode' (with the db: namespace visible) and 'data-mode' (where
the db: namespace is hidden).
in data-mode, the above is simply seen as the document
<xhtml xmlns="xhtml">
<body>
<p>blah blah</p>
<p>blah blah</p>
</body>
</xhtml>
part of the belonging collection.
Note: even in metadata-mode, the portability is still valid: XML:DB API
must only describe the 'schema' that will be queried from XPath, the
rest will be performed by the application.
It's rough and very superficial, I know, but it's a few random thoughts
that might sparkle interesting discussions.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: XNode API Proposal
Posted by David BERNARD <dw...@java-fan.com>.
Hi,
I'm not member of the development team but I've got some remarks.
- metadata attributes (created, modified...) depends of the target application, by examples my current application need some metadatas but my users is more important to know the source of data and is validity degree. So metadata are considered like other data and the association is done by using namespace
<data metadata:created="2001-10-22T18:33:56">
<metadata:modification date="2001-10-24T09:11:37" by="Toto" state="draf"/>
<metadata:modification date="2001-10-30T10:11:37" by="Mike" state="draf"/>
...
</data>
Others exemple if you need to mixed metadata used by several applications.
- target of metadata isn't only document. A document can be a collection of sub-info and application can need "metadata" on each. By examples a document can be a complete faq, todo-list because the source is one file.
So (IHMO) your API is more a part for a Xindice application toolkit, optionnal pack, or guide lines, tips...
Because metadata is only a point of view : metadata are data.
> ------------------------------------------------------------------------
>
> Description
>
> Since Xindice has no general method for associating metadata with each
> "record" in the database, XNode was developed for this purpose. XNode
> is a very simple API, only five files (including an Exception class).
>
> An XNode is an object acting as a container for XML content by providing
> an envelope element and some basic metadata attributes such as a node ID
> (nid), a timestamp, etc. If you're familiar with SOAP, it'll seem similar.
>
> An instance of such markup (wrapping an XHTML document) might appear as:
>
> <xnode:Envelope xmlns:xnode="http://www.apache.org/xnode/1.0/"
> xnode:id="n3892">
> <xnode:Header
> xnode:created="2001-10-22T18:33:56"
> xnode:modified="2001-10-24T09:11:37" />
> <xnode:Body>
> <html xmlns="http://www.w3.org/1999/xhtml">
> [document content]
> </html>
> </xnode:Body>
> </xnode:Envelope>
>
> Substituting "SOAP-ENV" for "xnode", this is notably similar to a
> *very* simplified SOAP (which for having "Simple" in its title
> isn't in the end all that simple). The above code is how an XNode
> is stored in Xindice, such that upon extraction the XNode object
> can be reconstituted. The XNode <xnode:Header> element is designed
> to be extended for other purposes, though 'created' and 'modified'
> should be supported.
>
> ----------------------
>
> Classes and Interfaces
>
> XNode abstract class:
> the XNode object, a wrapper for XML content.
>
> XNodeException class:
> extends Exception for exceptions thrown in XNode processing.
>
> XNodeState final class:
> defines a fixed set of enumerated types as processing states.
>
> XNodeFactory interface:
> defines an interface for a factory for creating XNode objects.
>
> XNodeStore interface:
> defines an interface for a processor for connecting and
> disconnecting from a Xindice server as well as common
> Collection and Node manipulations (create, get, delete, etc.)
>
> ----
>
> Comments welcome.
>
> Murray
>
> ...........................................................................
> Murray Altheim <mailto:murray.altheim@sun.com>
> XML Technology Center, Java and XML Software
> Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., Menlo Park, CA 94025
>
> Corporations do not have human rights, despite the
> altogether too-human opinions of the US Supreme Court.
--
--------------------------------------------------------------
David "Dwayne" Bernard Freelance Developer (Java)
mailto:dwayne@java-fan.com
\|/ http://dwayne.java-fan.com
--o0O @.@ O0o-------------------------------------------------
Re: XNode API Proposal
Posted by Murray Altheim <mu...@sun.com>.
Kimbro Staken wrote:
>
> On Tuesday, January 22, 2002, at 01:51 PM, Murray Altheim wrote:
>
> > This message describes the XNode, an API for use with Xindice that I've
> > sent on to Tom and Kimbro for review. This is considered a proposal, a
> > donation to the Apache project's Xindice code base. I'm interested in
> > hearing feedback, and if it's generally positive, the API would be
> > donated as part of Xindice. Sun will be releasing a UDDI registry project
> > soon that includes an implementation of this API. If accepted as part of
> > Xindice it'll be under an Apache license, if not, Sun will probably
> > maintain copyright of it. Since I'm leaving the company next week to
> > return to school I'm hoping the Xindice community accepts this donation,
> > as I'd like to see it become a part of Xindice (I'm the author).
> >
> > I'm hoping to post online the entire javadoc of the API sometime
> > soon. I'd send it to the list (a 32K zip), but I know how people
> > feel about attachments on listservers, and I'm not sure it'd get
> > through anyway. So below is a brief description in lieu of the more
> > extensive documentation.
> I posted your docs online http://www.xmldatabases.org/projects/xndoc/.
Thanks very much Kimbro.
> > ------------------------------------------------------------------------
> >
> > Description
> >
> > Since Xindice has no general method for associating metadata with each
> > "record" in the database, XNode was developed for this purpose. XNode
> > is a very simple API, only five files (including an Exception class).
>
> This is really an issue that we should resolve properly, i.e. by directly
> exposing this type of meta-data, rather then by just wrapping the content.
> I'm not sure how extensible we'll want that mechanism to be though. So it
> would be cool to have this available for people who want to have fully
> extensible meta-data. The real question is whether this is part of the
> core server or not. To me it doesn't seem like it should be, but then I
> also understand that may be the only way this can be released.
If I'm understanding this correctly, there's two ways that this could be
accomplished, probably more. First, one could use nested collections,
with an XNode-augmented Node containing further nested XNode-augmented
Nodes.
Or, more significant metadata mapping could be accomplished using XTM
topic map technology (which is also how I'll be doing this on my own
projects).
> Is there more to this that I'm not seeing? If this was included, is it
> something other people would find valuable? Would you be able to continue
> maintaining it?
Either myself or Jeff Suttor (who is project lead) would maintain it. If
it ever became an issue I would commit to maintaining it insofar as I am
able. There will be (as I mentioned) a Sun release of an implementation
of this API as part of our UDDI registry project (part of the Web Services
Pack).
To answer your question, there's not more than what you see. It's not a
complicated API, but I don't see that much more is needed. Much of the
work is done by XNodeStore and XNodeFactory, particularly in the latter,
the methods createXNode(), getXNodeAsDOM(), recreateXNode() and
serializeXNode(). These do a fair amount of work.
> > An XNode is an object acting as a container for XML content by providing
> > an envelope element and some basic metadata attributes such as a node ID
> > (nid), a timestamp, etc. If you're familiar with SOAP, it'll seem similar.
[...]
Murray
...........................................................................
Murray Altheim <mailto:murray.altheim@sun.com>
XML Technology Center, Java and XML Software
Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., Menlo Park, CA 94025
Corporations do not have human rights, despite the
altogether too-human opinions of the US Supreme Court.
Re: XNode API Proposal
Posted by Kimbro Staken <ks...@dbxmlgroup.com>.
On Tuesday, January 22, 2002, at 01:51 PM, Murray Altheim wrote:
> This message describes the XNode, an API for use with Xindice that I've
> sent on to Tom and Kimbro for review. This is considered a proposal, a
> donation to the Apache project's Xindice code base. I'm interested in
> hearing feedback, and if it's generally positive, the API would be
> donated as part of Xindice. Sun will be releasing a UDDI registry project
> soon that includes an implementation of this API. If accepted as part of
> Xindice it'll be under an Apache license, if not, Sun will probably
> maintain copyright of it. Since I'm leaving the company next week to
> return to school I'm hoping the Xindice community accepts this donation,
> as I'd like to see it become a part of Xindice (I'm the author).
>
> I'm hoping to post online the entire javadoc of the API sometime
> soon. I'd send it to the list (a 32K zip), but I know how people
> feel about attachments on listservers, and I'm not sure it'd get
> through anyway. So below is a brief description in lieu of the more
> extensive documentation.
>
>
I posted your docs online http://www.xmldatabases.org/projects/xndoc/.
> ------------------------------------------------------------------------
>
> Description
>
> Since Xindice has no general method for associating metadata with each
> "record" in the database, XNode was developed for this purpose. XNode
> is a very simple API, only five files (including an Exception class).
This is really an issue that we should resolve properly, i.e. by directly
exposing this type of meta-data, rather then by just wrapping the content.
I'm not sure how extensible we'll want that mechanism to be though. So it
would be cool to have this available for people who want to have fully
extensible meta-data. The real question is whether this is part of the
core server or not. To me it doesn't seem like it should be, but then I
also understand that may be the only way this can be released.
Is there more to this that I'm not seeing? If this was included, is it
something other people would find valuable? Would you be able to continue
maintaining it?
>
> An XNode is an object acting as a container for XML content by providing
> an envelope element and some basic metadata attributes such as a node ID
> (nid), a timestamp, etc. If you're familiar with SOAP, it'll seem similar.
>
> An instance of such markup (wrapping an XHTML document) might appear as:
>
> <xnode:Envelope xmlns:xnode="http://www.apache.org/xnode/1.0/"
> xnode:id="n3892">
> <xnode:Header
> xnode:created="2001-10-22T18:33:56"
> xnode:modified="2001-10-24T09:11:37" />
> <xnode:Body>
> <html xmlns="http://www.w3.org/1999/xhtml">
> [document content]
> </html>
> </xnode:Body>
> </xnode:Envelope>
>
> Substituting "SOAP-ENV" for "xnode", this is notably similar to a
> *very* simplified SOAP (which for having "Simple" in its title
> isn't in the end all that simple). The above code is how an XNode
> is stored in Xindice, such that upon extraction the XNode object
> can be reconstituted. The XNode <xnode:Header> element is designed
> to be extended for other purposes, though 'created' and 'modified'
> should be supported.
>
> ----------------------
>
> Classes and Interfaces
>
> XNode abstract class:
> the XNode object, a wrapper for XML content.
>
> XNodeException class:
> extends Exception for exceptions thrown in XNode processing.
>
> XNodeState final class:
> defines a fixed set of enumerated types as processing states.
>
> XNodeFactory interface:
> defines an interface for a factory for creating XNode objects.
>
> XNodeStore interface:
> defines an interface for a processor for connecting and
> disconnecting from a Xindice server as well as common
> Collection and Node manipulations (create, get, delete, etc.)
>
> ----
>
> Comments welcome.
>
> Murray
>
> .........................................................................
> ..
> Murray Altheim
> <mailto:murray.altheim@sun.com>
> XML Technology Center, Java and XML Software
> Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., Menlo Park, CA
> 94025
>
> Corporations do not have human rights, despite the
> altogether too-human opinions of the US Supreme Court.
>
>
Kimbro Staken
XML Database Software, Consulting and Writing
http://www.xmldatabases.org/