Re: LegalEntity Class (Was: Re: HumanML_Write: Several responses andsome reflection....)

[Rex Brooks <rexb@starbourne.com>]

Title: Re: LegalEntity Class (Was: Re: HumanML_Write: Several

Okay, I read the article, which is 2 of 3 and haven't read 1 or 3, which is to come. Didn't really change my mind, but it came close. Until I hear from almost everyone that they also prefer to learn UML in order to proceed with discussions, samples apps, etc, I'm going to stay with the more cumbersome, to this author's view, waterfall process I described before. Of course, if I was doing this alone, I might prefer to work with UML in the process described, but since I have now quite a lot of practice with UML in several IDEs and from scratch, I know what the learning curve is, and unless those among us with extensive XML and RDF experience care to either wait until the overarching UML work is done and then correctly apply it to their special areas of responsiblity, or learn UML to contribute, I think the concurrent approach is more practical, if more cumbersome, and allows those of us who want to build a UML model which will make subsequent application development easier and quicker to keep a concurrent reality check on our work to make sure is jibes with the XML and RDF underway.

As well, it keeps those nasty namespace complications down to manageable, and those of you who follow the xml-dev list know just how tricky that can be.

Ciao,

Rex

At 1:22 AM -0400 9/26/01, Joseph Norris wrote:

> Hello
> Everyone,
>  
> Whatever
> path we eventually choose to take; UML to Schema or Schema to UML, I
> am sure this particular article published at XML.com
> about mapping UML models into XML schema should be of
> interest.
>  
> Take a look
> at
>  
> http://www.xml.com/pub/a/2001/09/19/uml.html
>  
> Cordially,
>  
> Joe
> Norris
> jwnorris@humanmarkup.org
>  
> > ----- Original Message -----
> > From: Rex
> > Brooks
> > To: Bullard,
> > Claude L (Len) ; Rex
> > Brooks ; Joseph
> > Norris ; OASIS
> > Comment
> > Sent: Tuesday, September 25, 2001 9:39
> > PM
> > Subject: RE: LegalEntity Class (Was: Re:
> > HumanML_Write: Several responses and some reflection....)
> >
> > At 10:26 AM -0500 9/25/01, Bullard, Claude L (Len)
> > wrote:
> > > I suggest that if the UML models are to be pursued as
> > > a design tool, these will have to
> > > be the main
> > > focus, not the schemas or RDF or any software under development. 
> > > The
> > > reason is of
> > > course that UML is purported to be a conceptual model from which
> > > other
> > > implementation mappings can be made.  
> > > That's the theory.  The dilemma is that
> > > these can
> > > easily be considered as object-oriented designs, not data designs
> > > as
> > > we discovered
> > > in Phase 0. 
> >
> > I think it ought to be the other way round. I prefer
> > making the UML fit the Schemas and RDF. As of now we have no conflicts
> > and its just easier that way since the datatyping is already well
> > underway in the Schemata.
> > >  
> > > We did a few
> > > rounds of discussion in Phase 0 on this subject, but now that
> > > there
> > > are fresh
> > > members with different backgrounds, this should be revisited. 
> > > The approach
> > > from the
> > > Schemas perspective is to create a set of types that can be toolkits
> > > for
> > > creating
> > > HumanML documents/messages.   For this to work, they have to
> > > be
> > > usable by any
> > > implementation of the UML conceptual layers.  A schema, per
> > > se,
> > > is not a
> > > class design though one can construe that by considering
> > > abstract
> > > types as
> > > class definitions, but even then, these really are document
> > > designs
> > > or a way to
> > > define a namespace of markup that can be added into an
> > > existing
> > > document
> > > namespace.   Today, the schema draft collects types from
> > > the
> > > semiotics
> > > field (eg, signs, symbols, etc. for describing
> > > meaningfulness
> > > and some
> > > categories for environment, chronemics, proxemics, as well
> > > as gestural
> > > types (haptics)) and a hodge of identification types or
> > > surface
> > >
> > > characteristics.   These are useful but
> > > there is no implication about the
> > > implementation or processing of these.  
> > > However, without some very
> > > explicit
> > > notion of how HumanML markup is to be used, I think we have
> > > a
> > > disconnect
> > > between the Schemas and the UML.   That means,
> > > architecturally,
> > > we are in the
> > > weeds and are talking around each other.
> >
> > What I suggest is a very limited use of only the
> > appropriate classes needed to make HumanML_Write as it is currently
> > constructed for messaging and writing without tying ourselves up
> > trying to make it more than it needs to be at this stage. This would
> > require a few new classes to fit, but not a great deal of
> > work.
> >
> >  I don't see any necessity for choosing UML over the
> > XML and RDF Schemata. Nothing is set in stone at this point, and if it
> > comes down to a choice, I think as I've said before that we should do
> > xml and rdf and just bag uml, except as an adjunct conducted
> > separately, which anybody could do anyway. I'm not saying that just to
> > get out of a bunch more work, uml and oo, are good for a lot of stuff,
> > but more baggage than I think we need right now. I don't think we are
> > far enough along to know what kind of overarching design we need, and
> > you just about need to have that kind of vision to do uml well, unless
> > you don't mind reinventing things a few times. I mind.
> >
> > However, it is good to have feedback from our newer
> > members.
> > >  
> > > Comments from
> > > the list members are solicited on this subject. 
> > >  
> > > len
> > <snip>
> >
> > Ciao,
> > Rex
> > --
> > Rex
> > Brooks
> > GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
> > W3Address: http://www.starbourne.com
> > Email: rexb@starbourne.com
> > Tel:
> > 510-849-2309
> > Fax: By Request

-- 

Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com

Tel: 510-849-2309
Fax: By Request