RE: One definition of "syntax-neutral"

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

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