RE: [bcm] Groups - Intro to DITA for BCM/EPR Committees (Key E 2a Intro to DITA.ppt) uploaded

["Dan Pattyn" <danpattyn@austin.rr.com>]

I am in violent agreement on DITA residing in the ebXML registry and
orchestrating the classic browse-n-drilldown path model as a means to
implement terminology interchange interfaces (services?) which are a
necessary but not sufficient requirement for semantic interoperability.  We
had a 5 hour meeting on Saturday on Naked Objects as an interface for EPR
folders.  It became clear that in an occasionally connected environment the
architectural metaphor we ended up with was "process caching" in the health
care ecosystem using XDS (Cross Enterprise Document Sharing).  The other
architectural metaphor we ended up with was the Naked Objects combined
runtime/design time metaphor from SMALLTALK.  Think of the Naked Objects
environment as a "babyUML" environment where the process model is
dynamically decorated by the end user using the OO paradigm in Naked
Objects.  This enables the team to change their process.  The demo I saw on
Saturday, showed Naked Objects changing the associations between objects and
then letting Hibernate flush the objects to the DBMS automagically with
little code.  So the bottom line here.  I think we need a similar
environment on the client side like the registry side.  The nasty thing
about digital bags is the replication and caching issues.  Pointing to the
DITA references in the registry means caching "just the right amount" of
DITA "stuff" in the Digital Bag and the "stuff" has an architectural model
of process => a sequence and hierarchy of DITA maps (not topic maps here).
The Naked Objects environment allows further specialization of the process
(sequence and hierarchy of DITA maps).  It seems to make sense to bring over
the DITA maps from the beginning.  The dynamic wizard is really Naked
Objects mapping (or decorating) the DITA maps information model.

The above is my thoughts as of today on the client side.  As I said earlier,
I am in violent agreement on the registry side.  My darkest fear, maybe we
should look at a slave registry as a fat bloatware client to make the
replication and process caching issues easiers.  Maybe "process caching" is
giving two year olds razor blades to play with. Dan's Second Law of Systems
Engineering:  Only after you have reached the point of no return, can you
discern whether the green on the other side of the fence is cactus or grass.
(Texas Humor).  With that thought, good bye!
Dan Pattyn

-----Original Message-----
From: David Webber (XML) [mailto:david@drrw.info] 
Sent: Monday, January 10, 2005 9:11 AM
To: bcm@lists.oasis-open.org; danpattyn@austin.rr.com
Subject: Re: [bcm] Groups - Intro to DITA for BCM/EPR Committees (Key E 2a
Intro to DITA.ppt) uploaded

Dan,

I like this DITA stuff - but Im seeing a bit of a different angle than DITA
inside the eFolder directly.

Rather I'm seeing the DITA residing in the ebXML registry and orchestrating
the
classic browse-n-drilldown path model - with enhanced definitions -
particularly
creating easier to grok classifications and taxonomies - as an alternate to
pure
OWL or RDF.   So the eFolder points out to DITA references in registry.

Then the DITA model - instead of using XSLT - can point back to eFolders
with
steps in EPR task flows.  This seems to me to be easier and more intuitive
and
requiring less programming.

Overall I'm liking the augmentation EPR + DITA provides...since we always
knew that EPR needed a strong wizard capability to instruct users in a
sound and replicateable way.

This way also - I don't need to redraw too much of our XDS V2 PPT - just
add an extra book on the 'Registry' - with DITA and a hook from the
eFolder?!? ; -)

Am I missing something here?  Using DITA to structure the actual menus
inside the eFolder?  While possible - I'm not sure that is so clean - since
the work flows will be based on context and have programmable aspects
and links and switching.  Certainly though - DITA can add documentation
value there with associations to DITA topicmaps....

Thanks, DW

----- Original Message ----- 
From: <danpattyn@austin.rr.com>
To: <bcm@lists.oasis-open.org>
Sent: Sunday, January 09, 2005 11:21 PM
Subject: [bcm] Groups - Intro to DITA for BCM/EPR Committees (Key E 2a Intro
to DITA.ppt) uploaded


> Slides from Don Day, IBM Lead DITA Architect and Chair of the OASIS DITA
> Technical Committee.  DocBook used the book metaphor, DITA used the
on-line
> help metaphor. We should look at the implications of DITA as a set of
> design principles for creating specific types of information in a highly
> modular structure for the EPR "process folder metaphor".  As ebSOA
> architectures become more dynamic, the more granular and the more support
> for specialization is needed.  The Darwin in Darwin Information Typing
> Architecture references inheritance and specialization to create agility
> and interoperability support for electronic processes.
>
>  -- Mr Dan Pattyn
>
> The document named Intro to DITA for BCM/EPR Committees (Key E 2a Intro to
> DITA.ppt) has been submitted by Mr Dan Pattyn to the OASIS
Business-Centric
> Methodology (BCM) TC document repository.
>
> Document Description:
> Slides from Don Day, IBM Lead DITA Architect and Chair of the OASIS DITA
> Technical Committee.  DocBook used the book metaphor, DITA used the
on-line
> help metaphor. We should look at the implications of DITA as a set of
> design principles for creating specific types of information in a highly
> modular structure for the EPR "process folder metaphor".
>
> Download Document:
>
http://www.oasis-open.org/apps/org/workgroup/bcm/download.php/10910/Key%20E%
202a%20Intro%20to%20DITA.ppt
>
> View Document Details:
>
http://www.oasis-open.org/apps/org/workgroup/bcm/document.php?document_id=10
910
>
>
> PLEASE NOTE:  If the above links do not work for you, your email
application
> may be breaking the link into two pieces.  You may be able to copy and
paste
> the entire link address into the address field of your web browser.
>
> -OASIS Open Administration
>