Re: [COAS-List] SGML Thread on Report Types

[Wayne Wilson <wwilson@umich.edu>]

Tim Brinson wrote:
> 
>  One of the things I'm missing is how SGML
> architectures are suppose to work operationally.
>
Possibly useful collection of links can be found at:

http://www.oasis-open.org/cover/topics.html#archForms

In particular, the following link seemed to answer some of my questions:

http://www.isogen.com/papers/archintro.html#div-1-3
>
>  I understand how
> normal DTDs are suppose to work with XML but is seems these
> architectural DTDs are more meta information and I don't know when they
> come into play 
>
For an architectural aware engine, they come into play during processing
of the document.  An architecture provides a way to map (potentially
unknown) items into an architecturally defined item....  This is sort of
similar to MIME typing of image/jpeg or image/jif.  I can use MIME to
create a generic handler for images, then override that handler for
image/jpeg and yet I can present the MIME processor a new type called,
say, image/fractal and the processor will hand it off to the generically
defined image handler.  

 Another way of looking at it would be to consider the discussion of
types of documents versus specific documents, i.e. a dictation type and
a radiology or pathology instance.  The dictation type would be an
architectural form with a DTD defining elements.  The DTD for radiology
or pathology would include a mapping into the form elements within it's
DTD.  A processor for form could be engineered without specifying each
and every possible mapping that could be defined.
> 
> 
> My sense is that COAS does not need to treat them as BLOBs.  COAS it's
> self has a structuring mechanism.  I believe a COAS Observation is
> sematically similar (but not quite identical) to an XML Element.
> 
>  - The observationType in COAS is semantically equivalent to the an XML
> Element Name.
> 
So, since there can be an infinite (or so large as to appear infinite)
number of possible XML element names, we cannot pre-define them all. 
The use of architectural forms is an attempt to deal with this problem. 
Continuing with my image example, by creating a arch form element called
image and then indicating that all images should be handled by the image
viewer found at <some link address> in the architecture, I can then
create a new document called the medical fractal image analysis report
which includes a element defined as image fractal and linked explicitly
to the architectural form image.  Now, the medical fractal image
analysis report can be processed and when the image element is
encountered (for the first time ever, let's say) it's all about whether
the linked to program can handle a fractal image.  And, if it can't
today, the report is broken from the user perspective, but an upgrade of
the image handler program is all that is needed to fix the report!  The
element tagging and such of the report don't have to be changed at all. 
Thus, without needing to standardize on this new fractal report, it can
exist in our system!
> 
> Of course COAS does not do the presentation (rendering) but it is a
> mechanism that can be used to access clinically relevant information a
> provider needs at the point of care.
> 
Poor choice of words on my part, I did not mean presentation in the
rendering sense.  A better choice would have been to call it an
collection of information presented in the context of providing clinical
care.  The main point was to indicate that this was not necessarily
information only from the 'record' nor would it necessarily use the same
structuring conventions.