Hi all,

This is a legacy issue: in the original meta-model, Whitepaper is modeled 
as a subclass of Concept, that is, Whitepaper extends Concept. That's why 
Whitepaper is also classified in the concept category.

You could think some other ways to model this or use tags or something 
else to exclude them. 

Thanks very much.
Bing.



From:   [email protected]
To:     [email protected]
Date:   04/28/2011 12:08 PM
Subject:        epf-dev Digest, Vol 64, Issue 16
Sent by:        [email protected]



Send epf-dev mailing list submissions to
                 [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
                 https://dev.eclipse.org/mailman/listinfo/epf-dev
or, via email, send a message with subject or body 'help' to
                 [email protected]

You can reach the person managing the list at
                 [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of epf-dev digest..."


Today's Topics:

   1. Re: Whitepaper is appearing in concept categories (Bruce Macisaac)
   2. OMG, SPEM, SEMAT, and EPF (Bruce Macisaac)


----------------------------------------------------------------------

Message: 1
Date: Thu, 28 Apr 2011 11:38:08 -0700
From: Bruce Macisaac <[email protected]>
To: Eclipse Process Framework Project Developers List
                 <[email protected]>
Subject: Re: [epf-dev] Whitepaper is appearing in concept categories
Message-ID:
 <ofc0d7ddce.55b0c03b-on88257880.0065cd29-88257880.00665...@us.ibm.com>
Content-Type: text/plain; charset="iso-8859-1"

I am not able to replicate this issue.
Cristiano - if you export your plug-in and send it to me, I will 
investigate.

Bruce MacIsaac
Manager RMC Method Content
[email protected]
408-250-3037 (cell)



From:
Cristiano Gavi?o <[email protected]>
To:
[email protected]
Date:
04/21/2011 10:21 AM
Subject:
[epf-dev] Whitepaper is appearing in concept categories
Sent by:
[email protected]



Hi,

I'm experimenting some issue with custom categories for concepts and 
whitepapers.

I've create customs categories using as example this from epf pratices: 
core.default.nav_view.base

But when I publish any white paper appears in both White Papers and 
Concepts folder.

Is this a know issue ?

cheers

Cristiano
_______________________________________________
epf-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/epf-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://dev.eclipse.org/mailman/private/epf-dev/attachments/20110428/73ea07a1/attachment.htm
>

------------------------------

Message: 2
Date: Thu, 28 Apr 2011 13:07:35 -0600
From: Bruce Macisaac <[email protected]>
To: [email protected]
Subject: [epf-dev] OMG, SPEM, SEMAT, and EPF
Message-ID:
 <of600c1124.247ae421-on88257880.00649ad4-88257880.00691...@us.ibm.com>
Content-Type: text/plain; charset="us-ascii"

Dear EPF community,

The ESSENSE/SEMAT RFP is moving forward in OMG, and if we in EPF want to 
influence that standard, we need to provide an official response, 
preferably in the next week.  There will be further opportunities to 
comment on the RFP, but I would like to provide
an initial response to make it clear that this is important to EPF and we 
do plan to engage in the discussion.

I have attached the most recent version of this RFP that I have, and will 
post any updates as they become available.


I am working on an official response, but I need input from the community.
Specifically - it would help to have a list of who is using EPF content? 
Who has extended the tool and content, or built new tools or content based 

on EPF or SPEM?
Who would be impacted by a change to the underlying meta-model of EPF?
Please send a note to me at [email protected] so that I can compile 
comments.

Since EPF is based on SPEM, another OMG standard, it's in our best 
interest to make sure that any new OMG process standard fits
with SPEM and moves in a direction beneficial to EPF.

If there are changes you would like to see to SPEM, the meta-model on 
which EPF was based (http://www.omg.org/spec/SPEM/2.0/) let me know.  Also 

if you have specific comments on the RFP, or have feedback on the comments 

I expressed in my initial email on this topic (attached), please let me 
know in the next few days preferably.

Thanks to those who responded to my initial email on this topic:
John Allen, Diwant Vaidya, Chris Armstrong, Bob Palank, James F Tremlett.

I will add you to a "EPF/ESSENSE" interest group, and will copy you on my 
proposed official response to the RFP and solicit your input.
Anyone who wants to be added to this list, please send me a note.

Thanks,

Bruce MacIsaac
[email protected]
408-250-3037 (cell)




----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Dear EPF community, 

There was a recent submission to OMG to propose a new process standard. 
It is not based on SPEM or any of the work we have done in EPF, but rather 

is based on the SEMAT kernel work. 
(For those who don't know this, EPF was originally based on SPEM 
http://www.omg.org/spec/SPEM/2.0/ ) 

Some  reasons given for why the proposal ignores SPEM is: 

1. "lack of enactment support" 
If this is a significant concern, then a set of requirements for what 
would be appropriate enactment support should be described in the RFP. 
A goal to what people actually do vs. what they are supposed to do isn't a 

sufficient set of requirements. 
There are some hints in the RFP, but they aren't clear: 
"Methods can be queried to get guidance based on where you are and where 
you want to go" 
- this seems to be about describing how the processes evolve during 
enactment - this could be a natural extension to SPEM 

2."The notion of composable practices is not explicitly defined as a core 
concept in the SPEM metamodel" 
This seems to be a gap which could be addressed by a SPEM update.  Note 
that both SEMAT and EPF have gone beyond SPEM and 
added support for practices to their method offerings.  They both use 
similar concepts and provide similar capabilities, but not identical. 
This kind of divergence is exactly the kind of problem that standards 
organizations like OMG strive to avoid, so the time 
is ripe to add practices support to SPEM. 

3. "UML profile ... might be more complex and not as user-friendly as a 
more domain-specific language" 
There is also a MOF representation of SPEM, but in any case, any approach 
for simplifying is welcome, but doing something completely unconnected 
doesn't make a lot of sense. 

4. SPEM does not specify a kernel of "essential elements" 
Both SEMAT and EPF define such a kernel, but use different terminology and 

have made different choices regarding those essential elements. 
Again, this is where standards are valuable - they align the best of 
divergent ideas so that the entire community can benefit. 
The EPF kernel has been defined and publicly available for some time.   It 

is well supported by both the EPF Composer and Rational Method Composer 
tools. 
It is based on an extension to SPEM. 
A natural path forward would be to take the EPF kernel and formalize it in 

an extension to SPEM, reconciling differences with the SEMAT kernel to the 

benefit of the entire community.  I propose an extension, because I think 
SPEM should remain capable of modeling processes that don't use a kernel, 
or 
that use alternative kernels. 

If this is a topic that interests you, and you would like to be involved 
in this discussion, please drop me a note. 

Bruce MacIsaac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://dev.eclipse.org/mailman/private/epf-dev/attachments/20110428/fc2c4848/attachment.htm
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 11-02-01-RFP-AB-update2-final.doc
Type: application/octet-stream
Size: 278016 bytes
Desc: not available
URL: <
https://dev.eclipse.org/mailman/private/epf-dev/attachments/20110428/fc2c4848/attachment.dll
>

------------------------------

_______________________________________________
epf-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/epf-dev


End of epf-dev Digest, Vol 64, Issue 16
***************************************

_______________________________________________
epf-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/epf-dev

Reply via email to