Re: One definition of "syntax-neutral"

[KETELS Kris <kris.ketels@swift.com>]

OK. I would like to end this discussion or maybe we can continue off-line.
I merely wanted you to consider the reasons why namespaces were designed.And based on your comments, I still believe there are
equivalent ways of doing it. Reusability of elements, easy mapping between UML and XML, hierarchy, etc... are often wrong (to my
opinion) reasons to use namespaces (at least the way they are designed today)..

For example:
Why not use one namespace whereby an element would then be called:
CWMRDB.ActionOrientationType
>From a logical DB perspecitive, this is exactly the same. The only difference is the way they are organised physically.
Purpose of namespaces was primarily to differentlate elements between a known and an unknown repository.
I can clearly see why you want to use namespaces, but there are other ways.

By the way, using non-verbose namespaces makes me wonder why you are using verbose data elements. And I would love to find out why
OMG has decided to use namespaces for XMI.

Brs
Kris
(-:

"Iyengar, Sridhar" wrote:

> I should have been clearer.  The metamodel names (or model names which
> correspond to specific DTDs) get resolved to XML namespaces.  This mapping
> does NOT assume that namespaces are hierarhical.  By convention, OMG ( XMI
> specs recommend this) standard metamodel names are uniquely named.
> Metamodel versioning information can also be specified in XMI.
>
> Eg:   metamodel name : org.omg.cwm.resources.relational
>         XML DTD namespace : xmlns:CWMRDB
>
>         This model corresponds to a specific DTD assigned a specific XML
> namespace.  (CWMRDB as fragment below shows).  We also show (Actually
> generate cross rererence!) the other DTDs that this DTD depends on (all
> these dependencies are in the UML Model!)
>
>    <!-- The following must precede this DTD: -->
> <!--   XmiFixed.dtd -->
> <!--   Foundation.dtd -->
> <!--   DataTypes.dtd -->
> <!--   Model_Management.dtd -->
> <!--   KeysIndexes.dtd -->
> <!--   Behavioral_Elements.dtd -->
>
> <!ATTLIST XMI  xmlns:CWMRDB CDATA #IMPLIED >
>
> <!-- PACKAGE: CWMRDB:Relational -->
>
> <!ENTITY % CWMRDB:ActionOrientationType
>            ' xmi.value (  row| statement ) #REQUIRED'>
>
> <!ENTITY % CWMRDB:ConditionTimingType
>            ' xmi.value (  before| after ) #REQUIRED'>
>
> For example in the CWM metamodel (data warehousing) there are 27 DTDs each
> assigned their own metamodel name in the UML model (eg: Relational, Record,
> OLAP, Transformation...) and there is a generated DTD for each.  Together
> collectively we call these models CWM.  One or more of these DTDs can be
> used together as needed.
>
> When these DTDs or their corresponding documents are managed in repositories
> or directories, those implementations can use nesting if it makes sense -
> but this is outside XMI scope.
>
> Namespaces allows us to more clearly identify and refer to elements being
> used when multiple DTDs are referenced.
>
> -----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
begin:vcard 
n:Ketels;Kris
tel;fax:+32.2.655.45.52
tel;work:+32.2.655.44.85
x-mozilla-html:FALSE
org:S.W.I.F.T. sc;Standards
adr:;;;;;;
version:2.1
email;internet:kris.ketels@swift.com
title:Product Manager Standards Automation
x-mozilla-cpt:;1
fn:Kris Ketels
end:vcard