No Subject

I believe the first thing we would need is a COAS/DOM factory object
that takes an observation tree that was passed by value and returns a
reference to a DOM Document, DocumentFragment or Node, that encapsulates
the observation tree.  

Local libraries could be written by the application writer or provided
by a third party.

The ability to manipulate (modify) the structure should be OK since the
observation in the local context is a copy and is no longer associated
with the original observation on the server.


REMOTE CASE
-----------

In the current Service Model a client to COAS does a query (e.g. via the
BrowseAccess) and is returned object references to ObservationRemote
objects.  These ObservationRemote objects have operations to traverse
the observation tree.  We could consider replacing ObservationRemote
with the DOM Node interface and potentially adding any needed
operations.

For the remote case we don't need a DOM factory since COAS is about
accessing observations that already exist.

The DOM operations that modify the DOM tree are outside the scope of
COAS.  In general they would raise exceptions, not allowing
manipulation.  Particular COAS server implementations may allow
modifications if the observation is not yet part of a health record
(e.g. it is preliminary or is being used on ancillary systems).

Another issue with using DOM on remote objects is the assumption of
object identity by some of the operations on the Node interface
(insertBefore, replaceChild, removeChild).  These take an object
reference that the Node implementation is suppose to recognize as one of
its siblings.  Object identity is not something that can be guaranteed
by an object reference.  An implementation would need a reliable
mechanism for providing the identity.  It seems plausible but I don't
know of people doing this.



Well that addresses the main issues I can see with using DOM in COAS. 
On the one hand I see great synergy's with other standards work in this
area if we can use it.  On the other hand our information models don't
line up exactly.  Should we ignore the differences and go on?  Should we
align the COAS Information Model to be closer to an XML document? 
Should we not give direct support for DOM?


Happy Holidays.


Tim Brinson
--------------79D6E0B364C4B7D7FB8AD91A
Content-Type: text/x-vcard; charset=us-ascii;
 name="tim.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Tim Brinson
Content-Disposition: attachment;
 filename="tim.vcf"

begin:vcard 
n:Brinson;Tim
x-mozilla-html:TRUE
org:Protocol Systems, Inc.
adr:;;8500 SW Creekside Place;Beaverton;Oregon;97008-7107;USA
version:2.1
email;internet:tim@protocol.com
title:Systems Software Lead
tel;fax:503 526 4200
tel;work:503 526 4392
note:<img src=http://aco.protocol.com/pids/tbrinson.jpg>
x-mozilla-cpt:;0
fn:Tim Brinson
end:vcard

--------------79D6E0B364C4B7D7FB8AD91A--