RE: [legalxml-intj-exmndr] Review of Tom's Section 2 Draft

["Scott Came" <scott@justiceintegration.com>]

By "generated from what..."  I meant, what is the input artifact into whatever tool is used to generate the
UML?

I don't see a lot of value (in terms of enhanced interoperability) in generating a UML class diagram
from a schema (e.g., as David Carlson's hypermodel tool does), assuming you already have the model in some other
form.  For a reasonably complex schema, the diagram that is drawn by a tool is generally going to be pretty messy (we
saw this when we tried to reverse-engineer the NDEx schemas into hypermodel.)  And in any case, anyone can generate a
model from the schema at any point...there isn't much value in including it in a GIEPD.  Or they can view it in the
XMLSpy graphical editor.  It doesn't matter, because the schema itself is the locus of interoperability at that point,
not a diagram generated from it.

Look at it this way...  when considering a diagram, I think we should have
clearly in mind who the audience of the diagram is.  If you think of generating a class diagram from a schema, then
I'm guessing the intended audience is the developer who will build off the schema.  But if a developer is going to be
working with schema, my guess would be that developer can just read the schema.  Or, if he/she really wants a
graphical view, he/she can easily generate it.  There's no interop gain from requiring the UML diagram.

The
audience of a domain model is the group of business experts charged with documenting what the structure of the
document should be.  Domain modeling is the first step in the process, and so there's nothing to generate it from.

I suppose you could generate a class diagram from other "visualization techniques" (e.g., the
traditional spreadsheet or semantic concept maps)...  but again, I would question what the value of doing that is.  By
the time you do that generation, the important domain modeling function has been completed (getting business experts
to agree on the structure.)  If you've already recorded that information in some other way, I don't have an issue with
regenerating it in a different format, but wonder what the value of doing that is.

We've agreed in the past
(and I still agree) that UML is not the only format for the domain model.  I do believe we should establish a small
set of viable formats (e.g., traditional spreadsheet, concept maps, UML) and that we should **not** express those
formats in terms of tools.  (For example, it's UML, not Argo, Rational Rose, or Poseidon.  A good litmus test, in my
view, is that a workgroup should be able to construct the model on a whiteboard if they want...whether anyone would
actually ever do so or not, it forces us to be tool- and vendor-agnostic.)  If any vendor out there has a diagramming
technique that can be described precisely in a place separate from (or at least separable from) the vendor's tools,
then we should absolutely consider putting it on the list.  (Of course, I'd feel compelled to include that description
in the specification, which may raise some IP issues, but we could deal with that as it arises.)  However, as an OASIS
TC, I think we should always favor open industry standards.

The purpose in creating the MNDR (and each
section therein) is to attempt to gain interoperability beyond what is provided by XML Schema and GJXDM.  If we don't
restrict the domain model down to a few options, then we dramatically decrease the probability that people can
exchange models with each other, and then use them as a starting point for new work.

Final point...  we're
not claiming to tell anyone how they must do their work.  People who like using a tool that produces a domain model
format other than one of the ones we specify can continue doing so, and still could remain conformant with the other
sections of the MNDR.  In fact, someone could decide domain modeling is just a bad idea, and could jump right to
schema creation, and as long as they adhered to the rules in sections 6 and 7, they could rightfully claim conformance
with those sections.

> Re: "UML Class diagrams may be a generated artifact..."
> 
> URL Integration's Data Modeler could for one. I've been told there are
> also plenty of business-rules
tools out there that could do the same. I
> know Scott's had great sucess with using UML directly in a working
group
> setting, but not all working groups are going to have a facilitator of
> Scott's caliber. We
need to keep the door open to other methods and
> tools while stressing the use of UML as the final
representation.
> 
> Re: "UML Class diagrams...are not necessarily the instrument used to
> determine the data and relationships"
> 
> The alternative would be whatever the business
tool used. Data Modeler
> has its visualization method. Other tools would have their own. It's
> just
a simpler means of getting to the same point that Scott gets to
> directly in UML. Would it be better to say
"are not necessarily the
> initial instrument used to determine the data and relationships"?
> 
> 	-----Original Message-----
> 	From: Scott Came [mailto:scott@justiceintegration.com]
> 	Sent: Tuesday, March 22, 2005 12:50 PM
> 	To: legalxml-intj-exmndr@lists.oasis-open.org
>
	Subject: [legalxml-intj-exmndr] Review of Tom's Section 2 Draft
> 
> 
> 	Tom and fellow
subcommittee members:
> 
> 	I've just had a first look at Tom's draft of Section 2. I think
>
it's a good start, with section headers for the appropriate stuff.
> 
> 	I have one substantive
comment. Tom, on lines 135-138, you
> suggest that "UML Class diagrams may be a generated
artifact..." My
> question is, generated from what?
> 
> 	Also, if "UML Class
diagrams...are not necessarily the
> instrument used to determine the data and relationships"...what
> alternative instrument would you suggest?
> 
> 	Thanks.
> 	--Scott
> 
>
	Scott Came
> 	President and Principal Consultant
> 	Justice Integration Solutions, Inc.
>
	Olympia, Washington
> 	360-402-6525
> 	scott@justiceintegration.com
>
	http://www.justiceintegration.com
>

>
>