RE: One definition of "syntax-neutral"

[Arofan Gregory <arofan.gregory@commerceone.com>]

Folks:

I have to agree with Kris. Namespaces is not what it needs to be - due to
the lack of hierarchy - leaving it up to individual implementors to decide
how hierarchy will be represented within XML namespaces.

Here at C1 we have run into this same set of issues: we have a
product-specific set of conventions for indicating namespaces, but have
tried not to rely on it heavily for CBL.

Cheers,

Arofan Gregory
Document Engineering
Commerce One

-----Original Message-----
From: KETELS Kris [mailto:kris.ketels@swift.com]
Sent: Monday, February 14, 2000 4:19 AM
To: Iyengar, Sridhar
Cc: Cory Casanave; Arofan Gregory; 'Nikola Stojanovic';
ebxml-core@lists.oasis-open.org; ebXML-Architecture@lists.oasis-open.org
Subject: Re: One definition of "syntax-neutral"


I have a lot of reservations to use namespaces to solve problems that
namespaces never intended to solve (and were not designed to
solve either).
Would you mind explaining the rationale behind using Namespaces for XMI.
Namespaces at first sight sometimes offer a solution, but
in many cases cause much more other problems (e.g. URL's cannot be used
hierarchically)

Thanks
Kris

"Iyengar, Sridhar" wrote:

> 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