gXML: Reinventing XML in Java
Amelia A. Lewis
TIBCO Software Inc.
Eric E. Johnson
TIBCO Software Inc.
Problems with XML in Java
- Multiplicity
- how many tree models?
- Variability
- sorry, that concept does not exist.
- Interoperability
- you can't do it that way.
- Weight
- that document is too large.
[any material that should appear in print but not on the slide]
New specifications
- W3C XML Schema
- XQuery 1.0
- XPath and XSLT 2.0
- XQuery and XPath Data Model
- ... and more
[any material that should appear in print but not on the slide]
An XDM-based solution
- Handle/Body pattern
- Generics:
N: the "Node" abstractionA: the "Atom" abstraction
- XDM
- Immutability
[any material that should appear in print but not on the slide]
The gXML API (conceptual)
[any material that should appear in print but not on the slide]
Building bridges: the base
- Understand
- Look at existing bridges
- Decide what the
<N>ode abstraction is
- Implement
ProcessingContextandModelCursor(easiest:CursorOverModelfrombridgekit)FragmentBuilderDocumentHandler(easiest:DefaultDocumentHandlerfrominput-output)
- Verify conformance
bridgetestmodule- Test with any gXML processors (they may provide test suites)
[any material that should appear in print but not on the slide]
Building bridges: supporting mutability
- Examine the tree model's mutable APIs
- Implement
MutableContext(return fromProcessingContextinstead ofnull)MutableModelMutableCursor(bridgekitprovidesMutableCursorOnMutableModel)NodeFactory(creates the nodes that cursor and model position)
- Verify conformance (
bridgetest, processors requiring mutability)
[any material that should appear in print but not on the slide]
Building bridges: schema awareness
- Understand
- Examine typed extensions for existing bridges
- Decide what the
<A>tom abstraction is (XmlAtom?)
- Implement
TypedContext(which is-aSmSchema)TypedModelandTypedCursor(bridgekitfor cursor)AtomBridgeandMetaBridge(XmlAtomimplementations ready-made)SequenceBuilder
- Verify conformance
bridgetesttyped tests- Any gXML processor that uses the typed extensions
[any material that should appear in print but not on the slide]
Processors: transformation vs. mutation
- Mutation
- Most familiar pattern
- Refactoring is straightforward
- Full tree in memory?
- Concurrency issues
- Often unnecessary
- Tree models vary significantly
- Transformation
- Concurrency, deferred loading
- "Second copy" issue
- Mutable tree models can undermine
- Extensive refactoring
[any material that should appear in print but not on the slide]
Processors: stateful vs. stateless
- Stateful:
public class Processor<N> { private N state; }- Advantages: straightforward, compact, can persist
- Disadvantages: parameter propagation, single model
- Stateless:
public class Processor { public <N> N process(N node); }- Advantages: multiple models
- Disadvantages: complexity, external type-safety
[any material that should appear in print but not on the slide]
Processors: refactoring
- Incremental refactoring: introduce parallel gXML-based API
- Pervasive refactoring: redesign for immutability & transformation
- Advantages
- multiple tree models (without code bloat)
- runtime injection (esp. optimized models)
- code generally less awkward
- gradual change possible
- Disadvantages
- virtual call overhead
- less familiarity (initially)
[would be nice to have a real sample here]
Opportunities
- Specifications: XQuery, XSLT 2.0, XPath 2.0, even Schema?
- Interoperability: reconciling existing tree models?
- Dependency inversion: domain-specific tree models? non-XML models?
- Performance: concurrency, limited-memory solutions?
[any material that should appear in print but not on the slide]
Summary
- No conflict with current models; can reconcile competitors
- Enhanced functionality from current state of modeling
- Easy to implement bridges and processors and to refactor processors
- Provides a path toward implementation of new specifications
- Creates an environment in which optimization is possible
[any material that should appear in print but not on the slide]
Contacts and resources
Get involved!
- Authors: <alewis@tibco.com>; <eric@tibco.com>
- Mailing list <gxml-dev@yahoogroups.com>
- Website: http://developer.tibco.com/gxml/
- Blog: http://opensourcegxml.wordpress.com/
[any material that should appear in print but not on the slide]