No Subject

At the meeting last week there were suggestions of using DOM (Document
Object Model) for browsing observation trees.  This would have a number
of advantages but also ramifications.  This email is meant to stimulate
discussions on the topic.  I hope some of you have a chance to read and
comment before the eminent holidays.

DOM could be used in two different places within the Service Model.  On
the one hand it could be used to traverse a local Observation tree that
has been passed by value from a server.  On the other hand the server
may be able to use DOM as the interface for traversing an Observation
tree instance that resides on the server.  Each of these have different
ramifications and will be treated separately through out most of the
following discussion.


GENERAL COMMENTS
----------------

The W3C used IDL to specify the DOM interfaces (as well as Java and ECMA
Script).  It would be natural to use DOM if the structure of
observations fits well into it.

DOM has a general set of interfaces (Level 1 Core) which includes some
XML specifics as well as more specific interfaces for HTML.  I am
assuming COAS would just consider using the Level 1 Core interfaces.  

There is a benefit that if DOM was used for browsing both local and
remote observations.  The application programmer would only have to
learn one API.

The DOM specification does not include constructors or factory objects
as they are seen as application specific.  We would need to have
factories for local DOM objects.

DOM does not include operations to convert a DOM tree to an XML
document.  It might make sense to add these.

Here are some ideas for mapping contents between COAS Information Model
and DOM objects:

	Observation <---> Node
	CompositeObservation <---> Element
	AtomicObservation <---> CharacterData
	ObservationQualifier <---> Attr #Except we might remove this from model
	ObservationReference <---> ??? #W3C still working on links

We would likely add operations to CharacterData to return the explicit
IDL data types of ObservationValues.

HL7 is planning to use XML as the serialization mechanism in Version
3.0.  Other standards organizations (e.g. CEN) are considering using XML
for things as well.  Since DOM is an XML API we could harmonize better
with their efforts by using DOM.  This is important as the COAS
submitters will not be providing the full content for observations.  We
see HL7, CEN, DICOM, etc. as being the content experts.

ISSUE - To really harmonize our efforts the COAS Information Model needs
to be mappable to AND from XML.  We can not predict what features of XML
will be used by the various healthcare standards organizations.  To have
a complete harmonization the COAS Information Model should really be a
model of an XML document.  Any comments?

Some of the operations and interfaces for DOM don't have any meaning for
COAS.  We must weight the trade off of reusing this popular
specification against the confusion of these out of scope
operations/interfaces.  As an extreme example we would not use a common
interface if only 2% of the operations made sense in our context.  Where
do we draw the line?

ISSUE - If COAS does support DOM what do we say about the operations and
interfaces that have no meaning in the COAS context?

ISSUE - What if we find additional operations needed for COAS?  Do we
inherit and add our operations?  Or if we are removing some of the DOM
operations do we just use the same patterns as DOM and maybe the same
operation signature for the ones we have in common?


LOCAL CASE
----------

An Observation tree is passed by value from a server to a client.  The
ValueTypes defined for Observation do not contain operations since that
would require the client side to have implementations of the operations
whether they need them or not.  It is realized the ability of ValueTypes
to have operations can be powerful in distributed computing.  Declaring
them in a standard API such as COAS extends the requirements on the
client side beyond what is needed for interoperability.  If the client
did need SW to manipulate a local observation tree this fact should be a
hidden from the server that the observation tree came from.