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