[OASIS Issue Tracker] Commented: (SOAEERP-16) PR08-E8bQoS-Spec-cd03.pdf, Rating-Specification.pdf, BSLA-spec-cd03.pdf

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/SOAEERP-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20110#action_20110 ] 

Szu Chang  commented on SOAEERP-16:
-----------------------------------

The proposal needs to be clarified further in both how the schema will looks like, and how the spec should be changed to. 

Currently, the extension mechanism for the elements in XML schema is defined as: 

	<xsd:element name="Extension">
		<xsd:annotation>
			<xsd:documentation>Additional bQoS elements </xsd:documentation>
		</xsd:annotation>
		<xsd:complexType mixed="true">
			<xsd:choice minOccurs="0" maxOccurs="unbounded">
				<xsd:any processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
			</xsd:choice>
			<xsd:attribute name="optional" type="xsd:boolean" use="optional" default="true"/>
		</xsd:complexType>
	</xsd:element> 

Which already is for  elements of the list are name-value pairs, where the name is constrained of "Extension" and  the value can be "any". 

The specs have the following definition for the extension: 

This is an extensibility mechanism to allow different (extensible) elements to be specified in the future. Requesting new elements for future versions of the specification should be considered before developing possible dependencies upon attributes which may be deprecated in favor of such future elements. Unrecognized elements MAY cause a fault or be silently ignored.  

Is the proposal to change the name of the element from "Extension" to "EERP_Extension"? 

> PR08-E8 bQoS-Spec-cd03.pdf, Rating-Specification.pdf, BSLA-spec-cd03.pdf 
> -------------------------------------------------------------------------
>
>                 Key: SOAEERP-16
>                 URL: http://tools.oasis-open.org/issues/browse/SOAEERP-16
>             Project: OASIS Service-Oriented Architecture End-to-End Resource Planning (SOA-EERP) TC
>          Issue Type: Sub-task
>          Components: PR01 Comments
>    Affects Versions: cd03
>            Reporter: Paul Yang 
>            Assignee: William Cox
>            Priority: Critical
>             Fix For: cd04
>
>
>     * Suggestion: Please consider adding the following addition to all
>       items that read: "This is an extensibility mechanism to allow
>       additional attributes, based on schemas, to be added to the abbrvX
>       element in the future. _*Requesting new elements for future
>       versions of the specification should be considered before
>       developing possible dependencies upon attributes which may be
>       deprecated in favor of such future elements.*_ Unrecognized
>       attributes MAY cause a fault or be silently ignored." 
> WTC: This comment has several aspects. 
> (1) The management of new attributes in the extensibility mechanism has a request for specific text
> (2) The evolvability and management of the spec requires a mechanism ("requesting new elements..." needs management)
> (3) The conformance statements must say something about conforming behavior if an attribute that is not understood is receive (the commenter's suggestion is in the description above)
> (4) Note should be taken that an arbitrary "any" at the end of an object is a serious barrier to evolution; viz. W3C TAG notes over the past 5+ years.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira