[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]