[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 4/1/2005: Comment re: Quality Attribute Group (wd10-schema 2/22)
Everyone,
There has been more discussions and input regarding the quality and
documentSecurity attribute groups.
With inputs from Dale, John and others, I've developed a draft
recommendation that I believe represents our discussions, scope and
intent. I'd like to talk about these briefly on Tuesday. Please comment
prior to that time on any questions, updates or comments. Thank you.
John, if you have more comments, please send to the list.
*===========================================================================================================
*
*These matrices show whether or not each attribute in the attribute
group ‘quality’ can be specified as a restriction on the Requesting or
RespondingBusinessActivity for each concrete pattern (where it may or
may not be used). Operational semantics are held in the patterns rather
than the schema (i.e. no defaults are specified). For example, a ‘X’ in
isAuthorizationRequired for Request-Response indicates that this
attribute will be in the restriction list of available attributes for
this pattern. No default or use will be specified in the BPSS (schema).*
/REQUESTING/
Pattern/Quality
/CT/BT/
/LegacyBT/
/NOF/
/DataExchange/
/Req-Resp/
/Req-Confirm/
/Query-Resp/
/InfoDist/
1. isAuth
X
X
X
X
X
X
X
X
2. isIntel
X
X
X
X
X
X
X
X
3. isNonRReqd
X
X
X
X
X
X
X
N/A
4. isNonRRRReqd
X
X
X
X
X
X
X
N/A
5. timetoAR
X
X
X
X
X
X
X
X
6. timetoAA
X
X
X
X
N/A
N/A
N/A
N/A
7. retryCount
X
X
X
X
X
X
X
X
/RESPONDING/
Pattern/Quality//
/CT/BT/
/LegacyBT/
/NOF/
/DataExchange/
/Req-Resp/
/Req-Confirm/
/Query-Resp/
/InfoDist/
1. isAuth
X
X
X
X
X
X
X
N/A
2. isIntel
X
X
N/A
X
X
X
X
N/A
3. isNonRReqd
X
X
N/A
X
X
X
X
N/A
4. isNonRRRReqd
X
X
N/A
X
X
X
X
N/A
5. timetoAR
X
X
N/A
X
X
X
X
N/A
6. timetoAA
X
X
N/A
X
N/A
N/A
N/A
N/A
7. retryCount
N/A
N/A
N/A
X
N/A
N/A
N/A
N/A
Recommendations:
1. For correct use of restriction, name each attribute of the quality
attribute group that may be used by each concrete pattern (see matrices
above).
2. Do not define a retryCount on RespondingBusinessActivity on any
concrete pattern. Ask for business requirements on inclusion of such an
attribute on RespondingBusinessActivity. This is consistent with
previous versions.
3. In previous versions, documentSecurity existed on the Attachment and
DocumentEnvelope elements rather than the BusinessActionType. Our team
has identified that the documentSecurity may vary for the business
document and/attachment(s) based on the pattern used. What is the
preference on where to place the documentSecurity attribute group?
Decision TBD.
4. How do we restrict that there is only one logical business document
in the DocumentEnvelope in the current schema? We can have a logical
business document from many referenceable parts (i.e. more than one
namespace) but there should not be more than one logical business
document. This constraint is expressed in the annotation. How else is it
restricted in the schema?
5. On quality attribute group in technical specification, indicate more
attributes may be identified based on business requirements (i.e. for
DataExchange element, partners may decide they need to specify others we
may not know about). What change is suggested in the schema (if any)?
6. In previous versions, LegacyBusinessTransaction only used the pattern
attribute not a concrete pattern. Therefore the pattern attribute would
be used and not the explicit concrete patterns. Decision TBD on quality
group attributes (see #4 below).
7. In previous versions, RequestingBusinessActivity and
RespondingBusinessActivity were extensions of BusinessAction (see below)
and therefore took on these
defaults, regardless of what pattern was used. Example, see v1.05
snippet below. Therefore, recommend we either (1) not set a default on
or (2) set a default of ‘false’
on each specified quality attribute group attributes (effectively
leaving the decisions, the operational semantics, and guiding principles
outside of the XML schema).
<xsd:complexType name="BusinessAction">
<xsd:sequence>
<xsd:element ref="Documentation" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attributeGroup ref="name"/>
<xsd:attribute name="isAuthorizationRequired" type="xsd:boolean"
default="false"/>
<xsd:attribute name="isIntelligibleCheckRequired" type="xsd:boolean"
default="false"/>
<xsd:attribute name="isNonRepudiationRequired" type="xsd:boolean"
default="false"/>
<xsd:attribute name="isNonRepudiationReceiptRequired" type="xsd:boolean"
default="false"/>
<xsd:attribute name="timeToAcknowledgeReceipt" type="xsd:duration"/>
<xsd:attribute name="timeToAcknowledgeAcceptance" type="xsd:duration"/>
</xsd:complexType>
*===========================================================================================================*
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]