[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (SOAEERP-16) PR08-E8bQoS-Spec-cd03.pdf, Rating-Specification.pdf, BSLA-spec-cd03.pdf
[ http://tools.oasis-open.org/issues/browse/SOAEERP-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
William Cox updated SOAEERP-16:
-------------------------------
Proposal:
This applies to all of the specs with the "any" extensibility element.
"any" should instead be a list of artifacts in all versions of the specifications. The elements of the list are name-value pairs, where the name is constrained. the value can be "any".
All "official and approved' extensions have EERP starting the name, e.g. EERP_extension1. No other implementation may use that reserved prefix for names of extensions. [addresses conformance]
As the specs evolve and elements are brought in, there will then be no name conflict.
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]