OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-intj-exmndr message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]