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/
----------------------------------------------------------------------
