RE: One definition of "syntax-neutral"

["Iyengar, Sridhar" <Sridhar.Iyengar2@unisys.com>]

some of the reasons that made XMI 1.0 DTDs less readable include need for
fully qualified names to ensure interoperability.  We could not use XML
Namespaces (not recommended byW3C)  when specifying XMI 1.0.  Since then we
have included XML Namespaces support.  We also use XML attributes and
Elements to improve readability in XMI 1.1.  Several other changes also
focused on improvng readability.

At the end of the day certain amount of subjectivity goes into what is
'human readable' and what is not.  The XMI designers welcome this feedback.

Please send me some specific examples of ebXML UML models and we will be
glad to generate XMI 1.1 DTDs so we can have more concrete discussions.
Suggestions for improving XMI and UML can be sent to issues@omg.org

Our goal for XMI is to be VERY XML friendly - yet leverage the power of UML.

Note that work on reverse engineering XML DTDs and XML Schemas to
MOF/XMI/UML has begun.  This is a significant step forward to give DTD
designers freedom to innovate and yet leverage XMI and UML.  The OMG 'XMI
production for XML Schemas' RFP just issued will standardize mappings from
XMI to XML Schema and reverse engineering of DTDs and Schemas.  We are
waiting for Schemas to become a W3C recommendation before finalizing this
work.



-----Original Message-----
From: Cory Casanave [mailto:cory-c@dataaccess.com]
Sent: Thursday, February 10, 2000 2:54 PM
To: Arofan Gregory; 'Cory Casanave'; 'Nikola Stojanovic';
ebxml-core@lists.oasis-open.org
Cc: ebXML-Architecture@lists.oasis-open.org; Iyengar, Sridhar
Subject: RE: One definition of "syntax-neutral"


I agree that the DTDs should be human usable and assert that this is very
doable, but examples will be needed to prove this.

If you do not have a automatic and normative translation from your
specification to the DTD you will be relying on human creativity to keep
these in-sync, something that has proved less than reliable - particularly
when interoperability between independent parties is concerned.

I know that XMI 1.0 is seen as an example of a non-usable generated DTD,
please look as the current version of XMI for an updated opinion.  The eb
model can be very much simpler than the UML model, so it should be even
easier to make a DTD that is 99% as readable as a "hand coded" one, but one
than matches your business specification and technical architecture 100%.
Precision and consistency is, in this case, of the utmost importance.

Regards,
Cory

> ----Original Message-----
> From:	Arofan Gregory [SMTP:arofan.gregory@commerceone.com]
> Sent:	Thursday, February 10, 2000 5:23 PM
> To:	'Cory Casanave'; 'Nikola Stojanovic';
> ebxml-core@lists.oasis-open.org
> Cc:	ebXML-Architecture@lists.oasis-open.org
> Subject:	RE: One definition of "syntax-neutral"
> 
> Cory:
> 
> I have some concerns reagrding generated DTDs from UML models, and similar
> -
> from what I have seen, the DTDs tend to be highly unusable from a human
> perspective. Mostly, they describe the syntax of the modelling language,
> rather than capturing the semantic relationships that we are focusing on
> in
> the components group. The ecommerce world would not accept this type of
> DTD
> as useful.
> 
> That autogenerating DTDs/schemas be possible, I agree would be a good
> thing.
> That we generate DTDs and schemas *directly* from the modelling syntax I
> do
> not see as necessary, so long as we provide a mechanism for compliance
> with
> models, and some mechanism for automatic DTD and schema generation.
> 
> Cheers,
> 
> Arofan Gregory
> 
> -----Original Message-----
> From: Cory Casanave [mailto:cory-c@dataaccess.com]
> Sent: Thursday, February 10, 2000 2:19 PM
> To: Arofan Gregory; 'Nikola Stojanovic'; ebxml-core@lists.oasis-open.org
> Cc: ebXML-Architecture@lists.oasis-open.org
> Subject: RE: One definition of "syntax-neutral"
> 
> 
> I would hope that these are the same model!  The intent of the Meta-model
> is
> to embrace the requirements of ebXML from data types to process
> specifications.  These specifications should be complete and generate well
> defined DTDs.  What is being refereed to as the way to express "syntax
> neutral" components is exactly the same intent as the "modeling language"
> -
> a specification without explicit dependence on XML 1.0.  .  The groups
> working on this model are; Components, Business Process, Repository and
> Architecture - perhaps some way needs to be found to have common ground to
> produce or adopt this core Meta model of e-business.
> 
> Since some people like boxes and arrows (diagrams) while others like
> letters
> and braces (text languages) it may be necessary to have a UML and a simple
> XML representation of this same model.  The XML representation could then
> be
> used without a "modeling tool".  It has been shown that you can
> isomorphicly
> go back and forth between such representations.  I would also hope that
> this
> Meta-model is a small subset of what can be done in UML and probably would
> not include things like use cases.
> 
> Regards,
> Cory Casanave
> 
> > -----Original Message-----
> > From:	Arofan Gregory [SMTP:arofan.gregory@commerceone.com]
> > Sent:	Monday, February 07, 2000 6:19 PM
> > To:	'Nikola Stojanovic'; ebxml-core@lists.oasis-open.org
> > Cc:	ebXML-Architecture@lists.oasis-open.org
> > Subject:	RE: One definition of "syntax-neutral"
> > 
> > Nikola:
> > 
> > As for "ebXML" modelling language, I was referring only to the core
> > components descriptions. It appears that UML will be used for process
> > modelling and elsewhere, which is fine with me. Internal to the core
> > components group, we are discussing how to model the core components.
> > 
> > Cheers,
> > 
> > Arofan Gregory
> > 
> > -----Original Message-----
> > From: Nikola Stojanovic [mailto:nstojano@cjds.com]
> > Sent: Monday, February 07, 2000 2:29 PM
> > To: Arofan Gregory; ebxml-core@lists.oasis-open.org
> > Cc: ebXML-Architecture@lists.oasis-open.org
> > Subject: Re: One definition of "syntax-neutral"
> > 
> > 
> > > I was simply trying to summarize what I had read on the list serv
> > regarding
> > > UML. Personally, I feel that at a minimum we will need to add
> > documentation
> > > describing use and intent regarding our class descriptions.
> > >
> > 
> > I have to admit that I have not read all of the listserv postings, docs,
> > ...
> > Could you let me know which parts of the listserv are referring to UML
> and
> > such.
> > If by "use and intent" you mean something like Usage (Use Cases,
> > Scenarios,
> > ...) as a means to at least show how to use those components I would
> fully
> > agree with you. I would support that we shouldn't try to treat "Use
> Cases"
> > as a formal modeling technique, but I would imagine that they would be a
> > great help (examples) for people who would try to go along the ebXML
> path
> > after the guidelines, ... are done.
> > 
> > > My understanding is that we will have on-going work around the
> official
> > > ebXML modelling language. There has not either been agreement on which
> > > object model to use, and we shgould probably take a close look at this
> > > aspect of the problem. Thoughts?
> > >
> > 
> > I am not sure that we have too much time to evaluate this. As far as I
> > know,
> > there are already few ebXML groups that have been using UML. If there
> are
> > better modeling languages we should use them, but we need to justify
> such
> > decision. And modeling language is just a language; it doesn't cover
> > process, tools, ... I hope we can be consistent across the board
> regarding
> > issues like this.
> > 
> > Thanks
> > Nikola Stojanovic
> > ebXML-Architecture member