RE: Problems With Implementing XMLDB API

2002-01-13 Thread Jim Tivy
Hi Dare

Have a look at the XQuery and XPath Data Model document.  Both XPath2 and
XQuery share the same data model as defined in the document at
http://www.w3.org/TR/query-datamodel/.

You are right that primitive types are the schema primitive types - all the
usual suspects - float, decimal, double, datetime and about 20 others.

As well, the data model supports sequences of primitive types, sequences of
nodes (like nodesets)as well as a single node.  A node can be a document,
element, attribute, comment... At any rate, it is quite well spelled out in
the aformentioned document.

cheers
Jim

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Dare Obasanjo
> Sent: Saturday, January 12, 2002 7:48 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Problems With Implementing XMLDB API
>
>
> The valid return types from an XQuery query are XML schema types while the
> valid return types from an XPath 1.0 query are a boolean, string,
> number, or
> nodeset (is there one I've forgotten?). So the question is if the
> XML:DB API
> promotes the results of a query to their own type will they be XPath 1.0
> types, XML schema types or some hybrid?
>
> --
> THINGS TO DO IF I BECOME AN EVIL OVERLORD #59
> I will never build a sentient computer smarter than I am.
>
> - Original Message -
> From: "Jim Tivy" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, January 12, 2002 4:28 PM
> Subject: RE: Problems With Implementing XMLDB API
>
>
> > Hi folks
> >
> > This thread has got me thinking.  What is returned from a query
> is a value.
> > What is a legal value should be defined in the API spec.
> XQuery has define
> > what a legal value is in their data model doc (see w3c data
> model doc).  It
> > may be wise to adopt this as a valid value in the xmldb API as well.  In
> > this light, I would use the word Value instead of Resource.
> >
> > cheers
> > jim
> >
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > Behalf Of Dare Obasanjo
> > > Sent: Friday, January 11, 2002 8:35 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Problems With Implementing XMLDB API
> > >
> > >
> > > - Original Message -
> > > From: "Jonathan Borden" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Friday, January 11, 2002 3:05 PM
> > > Subject: Re: Problems With Implementing XMLDB API
> > >
> > >
> > >
> > > > Err, so "addResource" on a BinaryResource is OK _from an
> > > interface point of
> > > > view_ when "addResource" on an integer doesn't make sense?
> Do you really
> > > > mean this?
> > >
> > > Considering that a number of native XML databases store BLOBS
> > > including Tamino
> > > and eXcelon as well as the fact that a few XML-enabled
> databases support
> > > storing XML as blobs such as DB2 (XMLCLOB type) and Oracle (in
> > > regular CLOBs)
> > > I don't see why it should be unreasonable to expect an API that
> > > expects to be
> > > used by XML databases not to support storing binary resources.
> > >
> > > On the other hand expecting the database to expect to know
> how to manage
> > > floating point numbers and booleans is ludicrous in my opinion.
> > >
> > > > A collection/list/set of integers is a _perfectly_
> reasonable and well
> > > > understood entity.
> > >
> > > Not for storing in a XML database.
> > >
> > > > What makes this different then a collection that expects a
> list of XML
> > > > documents each of which is valid to a particular schema, or
> a parent XML
> > > > element into which you attempt to insert a child element that
> > > would make the
> > > > XML invalid?
> > >
> > > Because those are *validation* problems as opposed to *type*
> > > problems. In both
> > > cases the database knows how to support the types but they
> happen to be
> > > invalid in the case of booleans and integers they are not the
> > > correct type to
> > > be handled by the database
> > >
> > >
> > > --
> > > THINGS TO DO IF I BECOME AN EVIL OVERLORD #59
> > > I will never build a sentient computer smarter than I am.
> > >
> >

RE: Problems With Implementing XMLDB API

2002-01-13 Thread Jim Tivy
Hi folks

This thread has got me thinking.  What is returned from a query is a value.
What is a legal value should be defined in the API spec.  XQuery has define
what a legal value is in their data model doc (see w3c data model doc).  It
may be wise to adopt this as a valid value in the xmldb API as well.  In
this light, I would use the word Value instead of Resource.

cheers
jim


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Dare Obasanjo
> Sent: Friday, January 11, 2002 8:35 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Problems With Implementing XMLDB API
>
>
> - Original Message -
> From: "Jonathan Borden" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, January 11, 2002 3:05 PM
> Subject: Re: Problems With Implementing XMLDB API
>
>
>
> > Err, so "addResource" on a BinaryResource is OK _from an
> interface point of
> > view_ when "addResource" on an integer doesn't make sense? Do you really
> > mean this?
>
> Considering that a number of native XML databases store BLOBS
> including Tamino
> and eXcelon as well as the fact that a few XML-enabled databases support
> storing XML as blobs such as DB2 (XMLCLOB type) and Oracle (in
> regular CLOBs)
> I don't see why it should be unreasonable to expect an API that
> expects to be
> used by XML databases not to support storing binary resources.
>
> On the other hand expecting the database to expect to know how to manage
> floating point numbers and booleans is ludicrous in my opinion.
>
> > A collection/list/set of integers is a _perfectly_ reasonable and well
> > understood entity.
>
> Not for storing in a XML database.
>
> > What makes this different then a collection that expects a list of XML
> > documents each of which is valid to a particular schema, or a parent XML
> > element into which you attempt to insert a child element that
> would make the
> > XML invalid?
>
> Because those are *validation* problems as opposed to *type*
> problems. In both
> cases the database knows how to support the types but they happen to be
> invalid in the case of booleans and integers they are not the
> correct type to
> be handled by the database
>
>
> --
> THINGS TO DO IF I BECOME AN EVIL OVERLORD #59
> I will never build a sentient computer smarter than I am.
>
>
> _
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
> --
> Post a message: mailto:[EMAIL PROTECTED]
> Unsubscribe:mailto:[EMAIL PROTECTED]
> Contact administrator:  mailto:[EMAIL PROTECTED]
> Read archived messages: http://archive.xmldb.org/
> --
>

--
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe:mailto:[EMAIL PROTECTED]
Contact administrator:  mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
--


RE: Preparing for a new update

2001-07-25 Thread Jim Tivy
OK

Let me try:

Two documents doc1 and doc2.  Each document is represented by an repectively
InfoSet i1 and i2.  InfoSet i1 has a reference to InfoSet i2 via a key or
XPointer.

In a reference or linking case there are 2 infosets i1 and i2.  In XInclude,
wouldn't there be just one InfoSet ib which included both doc1 and doc2?

Incidently, the InfoSet spec says an infoset can only contain 1 document.

cheers
Jim

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Jonathan Borden
> Sent: Wednesday, July 25, 2001 9:33 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Preparing for a new update
>
>
> Jim Tivy wrote:
>
> > I would suggest that XInclude is an entirely different technology - more
> > like an entity expansion.
>
> It is fine to suggest this, but your suggestion provides no
> guidance to the
> characteristics of this "entirely different technology". If you read my
> reply to Paul, you should note how XInclude is different than DTD entity
> expansion.
>
> The question remains: different than what? My criterion remains
> that I would
> like to see a functional difference in an Infoset resulting from one
> mechanism or another. If the infosets are equivalent, then differences are
> merely syntactic sugar.
>
> -Jonathan
>
>
> --
> Post a message: mailto:[EMAIL PROTECTED]
> Unsubscribe:mailto:[EMAIL PROTECTED]
> Contact adminstrator:   mailto:[EMAIL PROTECTED]
> Read archived messages: http://archive.xmldb.org/
> --

--
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe:mailto:[EMAIL PROTECTED]
Contact adminstrator:   mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
--


RE: Preparing for a new update

2001-07-25 Thread Jim Tivy
I would suggest that XInclude is an entirely different technology - more
like an entity expansion.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Jonathan Borden
> Sent: Wednesday, July 25, 2001 7:11 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Preparing for a new update
>
>
> Paul Rabin wrote:
> > At 11:36 PM 7/24/01 -0400, Jonathan Borden wrote:
> >
> > >Well assuming the attribute is "xml:include" then this is identical to
> > >XInclude isn't it? Seriously, what is the essential difference between
> this
> > >'experimental linking facility' and XInclude?
> >
> > Jonathan,
> >
> > Actually, the attribute is xlnlink:href.  And it's a bit different from
> > XInclude, since there is no copying or re-parsing.
> >
>
> Ok I understand that the attribute has a different name (that is one
> difference). I still don't understand how it functions in a different way.
> In specific an implementation of XInclude acts _as if_ the
> included document
> was in the including document. Copying/reparsing etc are merely
> implementation issues. What I mean by  saying that they are equivalent is
> that the "Infoset" provided by both mechanisms should be the same, if not
> please explain how the stored XML Infoset is different.
>
> This is generally termed "transclusion" and has been long discussed (e.g.
> http://lists.w3.org/Archives/Public/w3c-sgml-wg/1996Dec/0318.html)
>
> Again, as far as I know, between the current mechanisms of XInclude and
> XLink the various well known mechanisms of reference and
> inclusion/transclusion are already specified.
>
> Particularly I have no idea what it would mean to be "somewhere in between
> XInclude and XLink". If there has indeed been invented a new concept
> pertaining to hypertext theory please explain this in more detail.
>
> -Jonathan
>
> --
> Post a message: mailto:[EMAIL PROTECTED]
> Unsubscribe:mailto:[EMAIL PROTECTED]
> Contact adminstrator:   mailto:[EMAIL PROTECTED]
> Read archived messages: http://archive.xmldb.org/
> --

--
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe:mailto:[EMAIL PROTECTED]
Contact adminstrator:   mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
--


Delete this test

2001-04-24 Thread Jim Tivy


> -Original Message-
> From: Kimbro Staken [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 24, 2001 11:03 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Implementation feedback
> 
> 
> Lars Martin wrote:
> > 
> > On Mon, 23 Apr 2001 17:52:05 -0700
> > Kimbro Staken <[EMAIL PROTECTED]> wrote:
> 
> > Why the Collection interface needs setter/getter for 
> ResourceType? Does
> > a Collection can not contain different Resources, e.g. DOM 
> and Binary?
> > Did I overlooked something here?
> 
> It can but this is mainly used to switch what representation you want
> for XML. e.g. SAX, DOM, Text. This is definitely the one 
> thing about the
> API that I'm not really happy with.
> 
> The use case looks like.
> 
> Collection collection = DatabaseManager.getCollection("some db uri");
> 
> // tell the API you want a DOMNodeResource when you call getResource()
> collection.setResourceType("DOMNode"); 
> 
> String id = "gladiator-2000";
> DOMNodeResource resource = (DOMNodeResource) 
> collection.getResource(id);
> Document doc = (Document) resource.getContent();
> 
> 
> BTW, do we really need to be able to support mixed binary/XML 
> within the
> same collection?
> 
> > 
> > > The Resource interface should have a getResourceType 
> method so that you
> > > can know what kind of resource it encapsulates.
> > 
> > sounds reasonable
> > 
> > > In Collection there should probably be a 
> getChildCollection method to
> > > retrieve a collection relative to the current collection.
> > >
> > > In Collection there is currently a getChildCollections method that
> > > returns a list of Collection instances. This would 
> probably be better as
> > > a listChildCollections method that returns a list of 
> child collection
> > > names instead of actual collection instances. You could then use
> > > getChildCollection to retrieve the Collection instances as needed.
> > >
> 
> Any opinion on this change?
> 
> > > In Collection there should probably be a way to test for 
> the existance
> > > of a Resource prior to retrieving/changing/deleting it.
> > >
> > > In Collection there should probably be a way to test for 
> the existence
> > > of a particular service.
> > 
> > Well I see the advantages of dedicated "exists" methods but 
> I'm not sure
> > whether they're really necessary?!
> > 
> > 1. proceeding you request:
> > 
> > if (collection.serviceExists("XPathQueryService", "1.0")) {
> >Service service = 
> collection.getService("XPathQueryService",
> >  "1.0");
> >service.setCollection(collection);
> >
> > }
> > 
> > or 2. current proceeding:
> > 
> > Service service = null;
> > if ((service = 
> collection.getService("XPathQueryService", "1.0"))
> >  != null) {
> > service.setCollection(collection);
> > 
> > }
> > 
> > Same for Resources
> > 
> 
> Done deal. null returns on getService and getResource if not found. 
> 
> 
> > > I think that's it for now.
> > >
> > > --
> > > Kimbro Staken
> > > Chief Technology Officer
> > > dbXML Group L.L.C
> > > http://www.dbxmlgroup.com
> > >
> > > 
> --
> > > Post a message: mailto:[EMAIL PROTECTED]
> > > Unsubscribe:
> mailto:[EMAIL PROTECTED]
> > > Contact adminstrator:   mailto:[EMAIL PROTECTED]
> > > Read archived messages: http://archive.xmldb.org/
> > > 
> --
> > 
> > --
> > 
> __
> > Lars Martin
mailto:[EMAIL PROTECTED]
> SMB GmbHhttp://www.smb-tec.com
> 
> --
> Post a message: mailto:[EMAIL PROTECTED]
> Unsubscribe:
mailto:[EMAIL PROTECTED]
> Contact adminstrator:   mailto:[EMAIL PROTECTED]
> Read archived messages: http://archive.xmldb.org/
> --

-- 
Kimbro Staken
Chief Technology Officer
dbXML Group L.L.C
http://www.dbxmlgroup.com

--
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe:
mailto:[EMAIL PROTECTED]
Contact adminstrator:   mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
--

--
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe:mailto:[EMAIL PROTECTED]
Contact adminstrator:   mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
--