OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ebxml-bp] [ebBP] 7/28/2004: Is Pattern Attribute Required? [RSD]


Monica,

My take on this would be to default it to BusinessTransaction as
the default value.

I do see some value in being able to specify 'InformationDistribution' - but
some of the other selections are very hard to differentiate the
difference between them - eg - QueryRespond - etc.

However - if there is an alternate mechanism - let's not have two
things do the same work!  Suggest we link them directly if this
is the case - eg - if you choose BusinessTransaction - then this means
that the other attribute can only be values 'X, Y or Z' etc.

My sense here is that we can rationalize and simplify here to just two
or three main options for V2.  Then if implementers come back later
and ask for more - we can address that then - right now I think we have
too many moving parts and no clear use cases for all but the most 
obvious two or three...

Thanks, DW
=======================================================================

Quoting "Monica J. Martin" <Monica.Martin@Sun.COM>:

> Discussion|OASIS.ebBP.DraftSchemaComments;
> Topic|;
> Point|Pattern attribute on collaboration types;
> Attachments|http://www.oasis-open.org/archives/ebxml-bp/200407/msg00123.html;
> 
> mm1@
> As briefly discussed in Monday's call, the 'pattern' attribute still 
> exists on: BusinessCollaborationType, BusinessTransactionType, 
> BinaryCollaborationType and MultipartyCollaborationType.
> 
>     * Do we need the 'pattern' attribute given the concrete pattern
>       elements such as CommercialTransaction?
>           o Could this support backward compatibility?
>           o Right now the attribute is not designated or required or
>             optional. If retained, suggest 'optional.'
>     * Do we specify a well-formedness rule or implementers' hint that
>       indicates if the concrete pattern elements are used, the optional
>       'pattern' attribute is not?
> 
> Please provide feedback. Dale, can you comment from the work you have 
> been doing on schema? Schema snippet included below. Thanks.
> 
> 
> Reference:
> Updated schema 26 July: 
> http://www.oasis-open.org/archives/ebxml-bp/200407/msg00123.html
> 
> Binary Collaboration Type snippet example:
> --------------------------------------------
> <xsd:complexType name="*BinaryCollaborationType*">
> - <#> <xsd:sequence>
>   <xsd:element ref="*Documentation*" minOccurs="*0*" 
> maxOccurs="*unbounded*" />
> - <#> <xsd:element name="*Role*" minOccurs="*2*" maxOccurs="*2*">
> - <#> <xsd:complexType>
> - <#> <xsd:complexContent>
>   <xsd:extension base="*RoleType*" />
>   </xsd:complexContent>
>   </xsd:complexType>
>   </xsd:element>
>   <xsd:element ref="*TimeToPerform*" />
>   <xsd:element ref="*Start*" />
> - <#> <xsd:choice maxOccurs="*unbounded*">
>   <xsd:element ref="*BusinessTransactionActivity*" minOccurs="*0*" />
>   <xsd:element ref="*CollaborationActivity*" minOccurs="*0*" />
>   <xsd:element ref="*ComplexBusinessTransactionActivity*" 
> minOccurs="*0*" />
>   <xsd:element ref="*Success*" minOccurs="*0*" />
>   <xsd:element ref="*Failure*" minOccurs="*0*" />
>   <xsd:element ref="*Transition*" minOccurs="*0*" />
>   <xsd:element ref="*Fork*" minOccurs="*0*" />
>   <xsd:element ref="*Join*" minOccurs="*0*" />
>   <xsd:element ref="*Decision*" minOccurs="*0*" />
>   </xsd:choice>
>   </xsd:sequence>
>   <xsd:attributeGroup ref="*name*" />
>   <xsd:attribute name="*pattern*" type="*xsd:anyURI*" />
>   <xsd:attribute name="*isInnerCollaboration*" type="*xsd:boolean*" 
> default="*false*" />
>   </xsd:complexType>
> 
> @mm1
> 
> 


http://drrw.net


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]