[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [mdt-sbvr.dev] Packaging convention
|
Dave, thanks for explaining the tooling and what I call
PackagingConventions.
I fully support the design to have packaging possibilities in the
tooling metamodel since its quite useful in larger
models/knowledgebases. As you mentioned UML is a good example.
I would also recommend that all the "toplevel" Sets such as Vocabulary
etc are also sbvr::Packages. so one can have a structure "inside" a
vocabulary with "owned" things. This will be quite useful for the use
case when the owned things are not reused in other places. It also makes
it easier to add and remove whole libraries.
An extra logic will of course be necessary, merging the Package
containment with Set's part-of semantics. One way would be to define
that all Vocabulary::ownedElements are also, automatically, part of the Set.
The PackagingConventions may also affect naming according a set of
NamingConventions. An example is that hierarchical naming, such as URL,
URI, IRI etc. is correlated with nested Packages. Its though a separate
issue.
Another, possible future, tooling extension would be to
introduce"semantical packages" that are related to partitioning,
categorization, contexts etc.
thanks
/anders
Dave Carlson wrote:
Anders,ing
Thanks for taking a look at this.
Is it correct to assume that currently the Top level container is
Package, that is hierarchal (nestable)?
If so then what are the concrete tooling relation(s) to Set?
If so what are the idea about relations to specific subs of Set, i.e.
Bodyofsharedmeaning, Vocabulary etc.?
First, in the SBVR spec metamodel, *none* of the associations are
composition, so none of the model elements may be a "root" for a
hierarchically nested model file. I tried to use Set for this, but chaning
the Set::elements property to composition would not satisfy other uses where
Set refers to other model elements, but does not own them.
BodyOfSharedMeanings and Vocabulary also refer to elements but do not own
them.
So I created Package only for use in the tooling metamodel to be this
top-level root that can own, by composition, any Thing in the model. I
propose that Package may be nested to assist modelers in organizing
vocabularies and rules in a modular design. I have a lot of experience in
working with UML modelers, and they always want to use packages to organize
a large model. I expect the same requirement from SBVR users.
If you look at the sample models attached to my 16 June posting, you'll see
that the nested package structure is flattened (and lost) when transforming
to the SBVR XMI exchange format. Similarly, importing an XMI exchange file
into the SBVR tooling metamodel would create one Package to represent the
XMI document root.
Just to test the thinking in the current design, what about
creating a
specific "Package" that is a single root packaging construct for a
tooling file? Maybe named SBVRToolModel or SBVRPackage os
similar to get
the reading a feeling that the content belongs to the SBVR
family of files.
This is exactly what Package represents. I don't see any need to add a
prefix, e.g. SBVRPackage. The similar model elements in UML are named Model
and Package, not UMLModel and UMLPackage.
If this project team decides not to support nested Packages in the tooling
model, just remove the recursive association and you will have a single
root. But please think about end-user use cases and the benefits of
organizing a very large SBVR model.
Regards,
Dave Carlson
_______________________________________________
mdt-sbvr.dev mailing list
mdt-sbvr.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev