Re: [ebxml-bp] name and nameID attributes on choreography/flowconstructs

["Monica J. Martin" <Monica.Martin@Sun.COM>]

> Yunker: I agree with Dale that the last solution, a group that makes 
> them optional, is the best resolution.
>
mm1: This is in line with a recent open question we discussed and I 
thought we had resolved (at least partially).

......In today's call we discussed the nameID well-formedness rules with 
the specific case of BusinessTransactionActivityType and 
BusinessTransactionRef. Where nameID references are required, such rules 
apply. For example, every time a complexType (such as 
AttributeSubstitutionType, DocumentEnvelopeType, 
CollaborationActivityType) is used, the nameID reference is required. 
Other complexTypes have an optional nameID reference (i.e. they may or 
may not be used - such as performsRoleRef on PerformsType). This 
discussion arose from a question raised by Sacha Schlegel related to 
businessTransactionRef.

I am fine with this solution of creating an optional group.

>     -----Original Message-----
>     *From:* Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
>     *Sent:* Friday, April 08, 2005 5:49 PM
>     *To:* ebXML BP
>     *Subject:* [ebxml-bp] name and nameID attributes on
>     choreography/flow constructs
>
>     Hima pointed out to me that except for the Transition element,
>     each control construct has a name attribute group in its type.
>
>     So Fork, Join, Decision as well as Start, Success and Stop all
>     have to have name and nameID values.
>
>     I agree with Hima that we probably need to make a uniform
>     stylistic decision.
>
>     I am not aware that there is any good use case anymore for needing
>     to refer to what used to be called the “pseudostates”.
>
>     The well-formedness constraints on what types of elements IDREFs
>     can refer to generally prevent referring to these states.
>
>     A no-op process (with no real states) could be formed by letting a
>     Start state reference Success termination. That is not a very
>     useful use case, however.
>
>     I am willing to leave names and nameIDs in if people think they
>     might be useful. If we do that, I would prefer to add the name
>     attribute group to Transition, just to make it easier to always do
>     the same thing.
>
>     I am also willing to remove the name attribute group from all
>     these states (which leaves me less comfortable somehow).
>
>     For fewest changes, we can add the attribute group to Transition,
>     even though these things are less than first-class entities.
>
>     We can either remove them all during our TC review or when we
>     update the version to 2.1 or 3.0.
>
>     Finally, we could introduce a second attribute name group, just
>     like our current one, except making the attributes optional. That
>     might be the best way to allow their use if and when needed but
>     not to clutter the notation with a lot of attributes that are
>     infrequently used.
>
>     Actually I like that last solution the best. I would like to see
>     some +1s before doing this as it seems slightly more than mere
>     editorial.
>
>     Dale Moberg
>