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: mailto:[EMAIL PROTECTED]
Contact administrator: mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
----------------------------------------------------------------------
