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. > > > _ > 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: 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. > > > > > > _ > > 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/ > -- _ 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/ --
RE: Problems With Implementing XMLDB API
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. > > > > > > > > > _ > > > 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: Problems With Implementing XMLDB API
Jim Tivy wrote: > 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. > Exactly, the XQuery 1.0 and XPath 2.0 data models have merged. If XML:DB is really going to be the standard API for XML databases, we need to track this work. That said, what is important is what we can do with 'it' not whether 'it' is named 'Value' or 'Resource'. The current XML:DB API and Model is good. We can simply subclass the Resource class as has been intended from day 1. Jonathan -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Problems With Implementing XMLDB API
- Original Message - From: "Jonathan Borden" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, January 12, 2002 8:11 PM Subject: Re: Problems With Implementing XMLDB API > Exactly, the XQuery 1.0 and XPath 2.0 data models have merged. If XML:DB is > really going to be the standard API for XML databases, we need to track this > work. That said, what is important is what we can do with 'it' not whether > 'it' is named 'Value' or 'Resource'. > > The current XML:DB API and Model is good. We can simply subclass the > Resource class as has been intended from day 1. IMHO, this is *not* the right decision. A Resource is supposed to be a type the database knows how to store/manage. The results of an XPath query are a _superset_ of the types that an XML database should know how to store. Clinging onto "XPath query results = = Resource" is sentimentalism and does not make for a well designed API. It is a choice that will lead to many users of the API shooting themselves in the foot and lots of exceptions at runtime (the worst kind) as people realize that not all implementors of the Resource interface are actually resources. A better solution would be to design support for XQuery/XPath 2.0 types and make sure that the types that correspond to nodes/nodesets/complexTypes implement the XMLResource interface. -- 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/ --
Re: Problems With Implementing XMLDB API
Dare Obasanjo wrote: > - 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. You are always entitled to your opinion. I can understand the sentiment of not wanting to mix XML and primitive datatypes other than 'string', but this is not the way of the world. The XPath 1.0 model already deals with strings, boolean values and numbers. Moreover, the strong message we are getting from the database community is in fact that there are many people who do desire 'XML' databases to handle boolean values, numbers and dates. This project, XML:DB aims to be a standard API for XML databases. Surely we want to handle the needs of people who are designing and using XML databases. I mean, if the API is not able to serve as an acceptable mechanism for executing an XQuery or an XPath 2.0, what is the point? Just because we support XPath 1.0, does not mean that we have ever intended to _limit_ ourselves to XPath 1.0. > > > A collection/list/set of integers is a _perfectly_ reasonable and well > > understood entity. > > Not for storing in a XML database. Again, you are entitled to your opionion. I suggest, rather than dictate what you personally think ought to be in an XML database, rather, read what others intend: http://www.w3.org/TR/query-datamodel/#sequences "... Note: Sequences replace node-sets from XPath 1.0..." You may find this ludicrous, but I believe the job of XML:DB is not to dictate to the XML community what an XML database ought to contain, rather to serve the needs of this community. [snip] > > Because those are *validation* problems as opposed to *type* problems. Validation and type are _closely_ related concepts. Hence the term: DTD Document _Type_ Definition, what is used for classical XML validation. Jonathan -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Problems With Implementing XMLDB API
Like saying goes about opinions,.everybody has one. I merely stated my opinion about the XML:DB API after the trying to implement Core Level 1 Conformance over eXcelon's DXE[0] . My last manager told me I was opinionated, over time you'll realize this too and not feel that I am trying to _dictate_ my will. Anyway I disagree that the return types from an XPath query should implement the Resource interface since it is a BIG assumption that the average NXD will know how to persist any return type from a query. APIs like XML:DB, JDBC, ODBC, etc are meant to be lowest common denominator, your suggestion is the duirect opposite of that and is instead a highest common denominator API (just like CORBA) and we know how those turn out. [0] I don't work for them I'm doing it for fun. -- THINGS TO DO IF I BECOME AN EVIL OVERLORD #59 I will never build a sentient computer smarter than I am. - Original Message - From: "Jonathan Borden" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, January 12, 2002 8:33 PM Subject: Re: Problems With Implementing XMLDB API > Dare Obasanjo wrote: > > - 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. > > You are always entitled to your opinion. I can understand the sentiment of > not wanting to mix XML and primitive datatypes other than 'string', but this > is not the way of the world. The XPath 1.0 model already deals with strings, > boolean values and numbers. > > Moreover, the strong message we are getting from the database community is > in fact that there are many people who do desire 'XML' databases to handle > boolean values, numbers and dates. > > This project, XML:DB aims to be a standard API for XML databases. Surely we > want to handle the needs of people who are designing and using XML > databases. I mean, if the API is not able to serve as an acceptable > mechanism for executing an XQuery or an XPath 2.0, what is the point? > > Just because we support XPath 1.0, does not mean that we have ever intended > to _limit_ ourselves to XPath 1.0. > > > > > > A collection/list/set of integers is a _perfectly_ reasonable and well > > > understood entity. > > > > Not for storing in a XML database. > > Again, you are entitled to your opionion. I suggest, rather than dictate > what you personally think ought to be in an XML database, rather, read what > others intend: > > http://www.w3.org/TR/query-datamodel/#sequences > > "... Note: Sequences replace node-sets from XPath 1.0..." > > You may find this ludicrous, but I believe the job of XML:DB is not to > dictate to the XML community what an XML database ought to contain, rather > to serve the needs of this community. > > [snip] > > > > Because those are *validation* problems as opposed to *type* problems. > > Validation and type are _closely_ related concepts. Hence the term: DTD > Document _Type_ Definition, what is used for classical XML validation. > > Jonathan > > > -- > Post a message: mailto:[EMAIL PROTECTED] > Unsubscribe:mailto:[EMAIL PROTECTED] > Contact administrator: mailto:[EMAIL PROTECTED] > Read archived messages: http://archive.xmldb.org/ > -- _ 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/ --
Resources and Types
An XML:DB "Resource" corresponds to a DOM "Node". The sub-type "XMLResource"
does directly correspond to a DOM Node, and hence supports the DOM Node
types.
Currently it is possible to support simple datatypes via this mechanism as
each of these datatypes has a textual representation, and hence can be
returned via a text node.
One option is for XML:DB to wait until the DOM becomes XML Schema aware and
leverage whatever mechanism DOM decides to convey type information. On the
other hand not every XML:DB implementation will be DOM oriented, e.g. they
might be SAX oriented, and SAX has not yet decided _if_ or how to handle
types.
Our options are roughly:
1) Forget types
2) Wait for DOM and SAX to become type aware (and then implement the type
aware versions)
3) Implement a _simple_ form of _optional_ type awareness in XML:DB
The XML:DB Resource is already most of the way there and with a relatively
small change could easily get there in terms of _being able_ to transmit
types _if the underlying database so desires_
To be clear, the mechanism I propose would allow detailed types to be
transmitted, but would largely allow the database to decide how much type
information to transmit.
The String Resource::getResourceType() currently returns either
"BinaryResource" or "XMLResource". I propose the following change:
class QName {
String namespace;
String localName;
QName(String ns; String ln) {
namespace = ns;
localName = ln;
}
}
QName getResourceType() // or better getNamedType()
QNames for types:
The two part QName mechanism for naming types is flexible, conforms to the
XML Schema mechanism for naming types and is consistent with XML itself.
We need to name a basic set of predefined types.
The simple/atomic types are named by XML Schema e.g
xsd:integer xsd:string xsd:boolean
which correspond to:
QName(http://www.w3.org/2001/XMLSchema, "integer") etc.
We may choose to name types given the XQuery Formalism e.g.
{http://www.w3.org/TR/query-semantics/, "AnyComplexType"}
corresponding to the current "XMLResource"
Given this mechanism I propose the following interface to represent
simple/atomic datatypes **as also defined by the java.lang package*:
interface SimpleTypeResource extends Resource {
Integer getInteger();
Float getFloat();
Double getDouble();
Long getLong();
Short getShort();
Boolean getBoolean();
String getString();
java.util.Date getDate();
void setInteger() ...
...
};
In order to implement _unnamed types_ e.g. those that might be specified by
a fragment of XML Schema or RELAXNG, another method is needed (such types
are not explicitly assigned a QName)
Resource getUnnamedType()
were the type specification may be returned as a DOM Node or series of SAX
events (the XML representation of the type). A reason to change the current
name:
getResourceType => getTypeName() is to eliminate confusion with a Resource
being used to specify a type (this will undoubtedly be a future issue).
So to recap, this simple type interface can be implemented on current XML:DB
implementations by replacing
getResourceType() => "XMLResource" with
getTypeName() => {xsd:anyType}
and
getResourceType() => "BinaryType" with
getTypeName() => {http://www.xmldb.org/datatypes, "binary"}
This is hence trivial to implement on top of current implementations, yet
provides the extensibility that will be highly valuable in future XML
database work.
Jonathan
--
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe:mailto:[EMAIL PROTECTED]
Contact administrator: mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
--
Re: Resources and Types
In addition I'd suggest that somewhere in the API a
QName[] getSupportedTypes( ) ;
is added as well as an error code be added in ErrorCodes such as
UNSUPPORTED_RESOURCE_TYPE
which can be one of the specified error codes when an XMLDBException is thrown
from a
Collection#storeResource( )
call. That is if this is the direction the XML:DB API decides to go in.
--
THINGS TO DO IF I BECOME AN EVIL OVERLORD #1
My Legions of Terror will have helmets with clear plexiglass visors, not
face-concealing ones.
- Original Message -
From: "Jonathan Borden" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, January 13, 2002 11:03 AM
Subject: Resources and Types
> An XML:DB "Resource" corresponds to a DOM "Node". The sub-type "XMLResource"
> does directly correspond to a DOM Node, and hence supports the DOM Node
> types.
>
> Currently it is possible to support simple datatypes via this mechanism as
> each of these datatypes has a textual representation, and hence can be
> returned via a text node.
>
> One option is for XML:DB to wait until the DOM becomes XML Schema aware and
> leverage whatever mechanism DOM decides to convey type information. On the
> other hand not every XML:DB implementation will be DOM oriented, e.g. they
> might be SAX oriented, and SAX has not yet decided _if_ or how to handle
> types.
>
> Our options are roughly:
>
> 1) Forget types
> 2) Wait for DOM and SAX to become type aware (and then implement the type
> aware versions)
> 3) Implement a _simple_ form of _optional_ type awareness in XML:DB
>
> The XML:DB Resource is already most of the way there and with a relatively
> small change could easily get there in terms of _being able_ to transmit
> types _if the underlying database so desires_
>
> To be clear, the mechanism I propose would allow detailed types to be
> transmitted, but would largely allow the database to decide how much type
> information to transmit.
>
> The String Resource::getResourceType() currently returns either
> "BinaryResource" or "XMLResource". I propose the following change:
>
> class QName {
> String namespace;
> String localName;
> QName(String ns; String ln) {
> namespace = ns;
> localName = ln;
> }
> }
>
> QName getResourceType() // or better getNamedType()
>
> QNames for types:
>
> The two part QName mechanism for naming types is flexible, conforms to the
> XML Schema mechanism for naming types and is consistent with XML itself.
>
> We need to name a basic set of predefined types.
>
> The simple/atomic types are named by XML Schema e.g
>
> xsd:integer xsd:string xsd:boolean
>
> which correspond to:
>
> QName(http://www.w3.org/2001/XMLSchema, "integer") etc.
>
> We may choose to name types given the XQuery Formalism e.g.
>
> {http://www.w3.org/TR/query-semantics/, "AnyComplexType"}
>
> corresponding to the current "XMLResource"
>
> Given this mechanism I propose the following interface to represent
> simple/atomic datatypes **as also defined by the java.lang package*:
>
> interface SimpleTypeResource extends Resource {
> Integer getInteger();
> Float getFloat();
> Double getDouble();
> Long getLong();
> Short getShort();
> Boolean getBoolean();
> String getString();
> java.util.Date getDate();
> void setInteger() ...
> ...
> };
>
> In order to implement _unnamed types_ e.g. those that might be specified by
> a fragment of XML Schema or RELAXNG, another method is needed (such types
> are not explicitly assigned a QName)
>
> Resource getUnnamedType()
>
> were the type specification may be returned as a DOM Node or series of SAX
> events (the XML representation of the type). A reason to change the current
> name:
>
> getResourceType => getTypeName() is to eliminate confusion with a Resource
> being used to specify a type (this will undoubtedly be a future issue).
>
> So to recap, this simple type interface can be implemented on current XML:DB
> implementations by replacing
>
> getResourceType() => "XMLResource" with
> getTypeName() => {xsd:anyType}
>
> and
>
> getResourceType() => "BinaryType" with
> getTypeName() => {http://www.xmldb.org/datatypes, "binary"}
>
> This is hence trivial to implement on top of current implementations, yet
> provides the extensibility that will be highly valuable in future XML
> database work.
>
> Jonathan
>
>
>
> --
> Post a message: mailto:[EMAIL PROTECTED]
> Unsubscribe:mailto:[EMAIL PROTECTED]
> Contact administrator: mailto:[EMAIL PROTECTED]
> Read archived messages: http://archive.xmldb.org/
> --
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe:mai
