(<Activity>
elements), each one containing
a description of the activity (<ActivityDescription>
)
and a sequence of result reports (<Result>
elements). Let us start with a set of simple evaluations.
<ProjectIdentifier>
),
delivered as a SortedSet<String>
object. A string representation of
the result might look like this:
<ActivityStartDate>
and
<Time>
) and inner values are activity identifiers.
Map<String, Map<String,String>>
.
A string representation might look like this:
<CharacteristicName>
and
<ResultSampleFractionText>
), inner keys specifying the timestamp
(concatenation of <ActivityStartDate>
and <Time>
)
and inner values a list of result values (each one a concatenation of
<ResultMeasureValue>
and <MeasureUnitCode>
)
obtained for this combination of sample kind and time.
Map<String, Map<String, String[]>>
.
A string representation might look like this:
UsgsResult
object arrays with string keys. The
key specifies the activity identifier and the objects are custom objects
representing an activity as described by one <Activity>
element. It is
assumed that UsgsResult
objects can be loaded from <Activity>
element information items.
Map<String, UsgsResult[]>
.
A string representation of the result might look like this:
ProjectData
looks like this:
ResultReport
, from which we
obtain the interfaces:
Object
.
Map<String, String>
is tailored exactly for the purpose of working
with a string-to-string mapping. At least in situations where only key-based
access is desired (as opposed to querying the sets of keys or values), the map may be
considered simpler and more straightforward. After all, working with the XML
representation one would have to be aware of three paths: one leading from the
map root to the nodes representing map entries, one leading from the entry root
to the key and one leading from the entry root to the value. (In the example,
the paths would be “project”, “@id” and “@name”.) These paths would have to be
supplied either by convention (for example using standardized element names
“map” and “entry” and attribute names “key” and “value”), or by explicit meta
information. So the XML representation needs meta
information. Another aspect: the navigation from key to value can be
achieved in different ways, e.g. via XPath or via DOM methods. So the XML
representation is not unambiguous and explicit as to the appropriate usage
style. Apart from that, the map access is probably more efficient. Taking
these aspects together, one may conclude that XML’s wonderful ability to
represent almost any kind of information does not imply that it is always
the most appropriate format for using or processing that information. This is where
“information units” come into play.
java.util.Map<String,String>
”. If, for example, a Perl implementation
of XQJPLUS existed, the corresponding Perl type name would probably be Hash
.
category | types |
---|---|
Boolean, BigDecimal, BigInteger, Byte, Double, Duration, Float, Integer, Long, QName, Short, String, XMLGregorianCalendar | |
Document, Element, Attr, Text, Comment, ProcessingInstruction |
category | types |
---|---|
Boolean, BigDecimal, BigInteger, Byte, Double, Duration, Float, Integer, Long, QName, Short, String, XMLGregorianCalendar | |
Document, Element, Attr, Text, Comment, ProcessingInstruction | |
|
|
List<String>, List<Node>, Set<String>, Set<Node>, SortedSet<String>, Queue<String> | |
java.util.Properties | |
(any type implementing LoadableFromXML) | |
InfoTrayLoadingException | |
InfoTray |
java.util.Properties
LoadableFromXML
, which is part of the main
package of XQJPLUS. It contains a single method loadFromXML
which
loads an object with data received as an XML node. The construction of custom type
objects will be discussed in a later section.
InfoTray
object, which represents
a collection of named information units. (See
InfoTray
objects as internal nodes and non-InfoTray
objects as leaf nodes.
In fact, a query result as a whole can be regarded as such a tree. Note that
the tree of info trays and non-tray leaves must not be confused with an
XML tree. A leaf of the latter contains an atomic value; a leaf of the
former may, for example, contain an XML document, or a mapping of strings to
XML documents.
<xqjp:part>
announces
the construction of an information unit with name “activityTimes” and physical type
“map_string_to_string_object”. This type name corresponds to the Java type
Map<String,String>
. The data to be written into the map follow
in the next result item, which is a <xqjp:part>
element) which specifies
all unit properties: name, meta information, type (physical, semantic, implementation types). Exceptions to this
rule are units defined to be an info tray. The assembly of such complex units is discussed in a special section.
<xqjp:setVar>
), which specifies
a name and minimal type information (atomic or node, single value or sequence). During the
assembly process, all data items following the declaration and preceding the next control
item are bound to a variable of the declared name. Thereafter, they can be referenced
by unit-defining control items (<xqjp:part>
) via a special attribute (“source”).
The following XQuery code illustrates this possibility by generating two maps backed by
the same data item. Map “activity2time” is string-to-string, whereas the inverse map
“time2activity” is string-to-string[]. Both maps are assembled from the contents of
control variable “activityDates”.
<xqjp:complexPartBegin>
and a <xqjp:complexPartEnd>
control item. As an embedded tray is an
information unit, the begin marker also plays the role of a unit-defining item. It must
specify the unit name and may specify a semantic type and meta data, just like any other unit-defining item.
LoadableFromXML
. This interface is defined in the main package of
XQJPLUS and contains a single method signature:
<xqjp:part>
or
<xqjp:complexPartBegin>
). The name of a meta data item is the respective attribute’s or
element’s name; the value is its string value. If a meta data item is specified by an attribute, the
attribute name must have a non-empty namespace URI. If a meta data item is specified as a child element, the
element name may or may not be in a namespace.
InfoTray
; and it models the loading from
an XQuery result by providing a subclass of InfoTray
implementing such a loading method. Other
subclasses of InfoTray
might be developed which load the tray from, say, an XSLT or XProc result,
or a set of delimited files or yet other kinds of data sources. Note that the read access methods are all harboured
by the InfoTray
level, as they reference only the assembled information units, never any information
about the assembly process. In consequence, once the tray is loaded the actual loading mechanism is
invisible from the Java perspective and may be replaced at any time.
InfoTray
define a data source-specific load method which assembles the units in a source-specific
way and adds them to the tray by calling the base class’s add
methods.
add
methodsInfoTray
with a
comprehensive set of source-independent add
methods. These methods receive a unit's completely assembled
data content, along with meta data and unit name. For each supported physical type, there is a
special add
method. Some examples:
InfoTray
. XQJPLUS provides
the subclass XQueryResponse
, defining a method
add
methods.
Map<String,String>
, on bloc as a
Map<QName,String>
or itemwise, specifying the meta data item name as a QName
or a Clark string. As when reading unit content, the unit is identified either by name or by passing a cursor.
<xqjp:trayMeta>
). The mapping of attributes and
child elements to meta data items is the same as with unit-related meta data.
<ts:part>
element.
InfoTray
class offers a method validate
, which validates the tray contents against a tray
schema. Note that this validation ignores all schema parts relating to the language binding. If errors are detected,
the validation writes one or more InfoTrayLoadingException
units, so that after validation the
diagnostics can be read from those units.
InfoTrayLoadingException
units with appropriate diagnostics. In other words it should not leave the
construction of exceptions to the validation. Following these steps for tray processing will help minimize problems:
validate
before checking for buffered exceptions;
later this call can be removed
InfoTray
member and defines
the specific access methods as described above. Along with this class, interfaces are generated according to the
directions given in the tray schema.
Object
:
Unit type (physical) | Interpretation of the intra-unit path |
---|---|
XPath | |
step 1: map key; no further steps allowed | |
step 1: map key; remaining steps: XPath | |
step 1: outer map key; step 2: inner map key | |
step 1: outer map key; step 2: inner map key; remaining steps: XPath | |
property name | |
not applicable | |
not applicable |
InfoSpace
represents an info space. Besides methods for adding
and removing trays from the space, it offers several methods for evaluating info paths,
distinguished by the result type (string, string array, node, node array), as well as a method
for setting/extending the namespace context for info path evaluation. An
InfoSpace
object represents a collection of information which combines high flexibility
(and possibly great heterogeneity) of information models with a unified, string-based access
model. This makes InfoSpace
objects an option for the design of highly configurable software:
configurations supply info path strings which connect generic functionality to actual input
collected from info spaces. As well as this, unified addressability of data supports data
integration in general. Just as XPath provides this addressability for XML data, info path
provides this addressability for info space data.
InfoTray
class. In fact, only a
new subclass of InfoTray
would have to be created, which implements the loading of a tray from the
chosen type of information resource. In particular note that the generation of Java code (info shapes) does
not need to be changed, as it is independent of the information resource underlying the tray. The major problem to
be solved would be to control the assembly of information units: the control exerted by XQuery result items
might prove difficult to attain with other sources.
InfoTray
. Then implement the loading of the tray from an XQuery
result, using the InfoTray
’s generic add
methods. Finally, extend the tray schema language
by a new language binding vocabulary, and implement the code generation controlled by that vocabulary.
<xqjp:XXX>
) and data items, which
generic Java code (XQJPLUS) assembles into an info tray.
xqjp:setNamespaceContext
sematype
which specifies the semantic type - XQJPLUS uses a special namespace context which
is xqjp:setNamespaceContext
control items.
Example:
xqjp:part
Map<String,<String, String[]>>
, as well as semantic and implementation types as
specified by the attributes “sematype” and “impltype”. The example specifies all five construction attributes
defined for the actual physical type (“outerEntryPath”, “outerKeyPath”, “innerEntryPath”, “innerKeyPath”,
“innerValuePath”) . If not specified, they would have defaulted to the values “*”, “@outerKey”,
“*”, “@key” and “*”, respectively. As meta data, “bi:source”, “bi:cr” and “laboratories” are specified. Note
that a special namespace treatment is applied to namespace-sensitive contents, e.g. to construction attributes
which are defined to contain an XPath expression - see preceding section.
xqjp:setVar
xqjp:error
xqjp:trayMeta
<xqjp:part>
element. Note
that the standard meta data “name” and “documentation” have names in the namespace
{http://www.bits-ac.com/xqjplus/meta}. Example:
xqjp:complexPartBegin
sematype
may specify the semantic type, and further attributes
and child elements may specify meta data of the unit in the same way as with
xqjp:part
items.
Examples:
xqjp:complexPartEnd
<xqjp:complexPartBegin>
item. The unit closed is the innermost
unit not yet closed. There are no attributes allowed. Example: