Task
|
i059 Interoperability Testing Plan
|
SOAEERP-42
|
William Cox
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
23/Jun/10 12:24 AM
|
04/Aug/10 09:32 PM
|
|
Planned TC level action item due 12/2010
|
Description
This issue separates the interoperability testing from the Related
issues listed below. This completes an action assigned to William Cox at
the 24 June TC meeting with respect to the related issues listed below.
Interoperability testing is required by OASIS for any OASIS standard
that is to be forwarded to any de jure international standards body.
This issue is to remind the TC to define, plan, and complete
interoperability testing during the creation of the specifications, not
as an afterthought when the specifications are nearly completed.
This applies after CD02 and prior to CD03.
Raised against / Related drafts
EERP-bQoS revision: WD04
EERP-Rating revision: WD05
EERP-SLA revision: WD04
Justification
N/A
Related Issues
i053i054i055
Origin
William Cox
Owner
Szu Chang
|
Proposal 12009-07-06
Define, plan, and complete interoperability testing. The definition and
plan is to be completed before CD03 and before any public review; the
implementation should be in parallel with specification development, and
must be started before any public review.
Proposal 2 2009-07-22
Discussed on 07/22/2009 TC meeting and it is concluded with this following:
Szu disagrees with the proposal 1, as Interop test is not a prerequisite of public review of three specs.
William Cox: Ation is not as Szu said -- it's not COMPLETE testing, it's complete a PLAN AND DEFINITION.
Andy suggested to change the title of the issue to the plan of interop testing and Bill suggested to chnage the title to "Interop testing plan". Then Andy: Retitle "Interoperability Test Plan"
No objection.The title of the issue is changed, and keep it open.
Proposal 3 2009-09-02
Per TC meeting on 09/02/2009, mark it as "defferred" and defer to post CD02. This issue will be addressed after CD02.
|
Task
|
i025 SLA Spec: CIQ Reuse
|
SOAEERP-41
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Won't Fix
|
23/Jun/10 12:21 AM
|
01/Sep/10 08:56 PM
|
|
|
Description
Can we reuse the OASIS CIQ specification for parties
(e.g. name, address, local government jurisdiction for both
individuals and organizations.
http://www.oasis-open.org/apps/org/workgroup/ciq/
# extensible Name Language (xNL V3.0)
# extensible Address Language (xAL v3.0)
# extensible Name and Address Language (xNAL v3.0)
# extensible Party Information Language (xPIL v3.0)
http://www.oasis-open.org/committees/download.php/29878/OASIS%20CIQ%20xPRL%20V3.0%20PRD01.zip
I think that at the least we should be aligned, but I would prefer to
use these specifications rather than do an incomplete job of
specifying our own requirements for a very legally complex set of
issues.
Cheers,
Rex
Raised against / Related drafts
EERP-SLA revision: WD04
Justification
N/A
Related Issues
Origin
Rex Brooks
Owner
Szu Chang
|
Proposal 12009-06-23
Current Service Provider in SLA schema is defined as:
<xsd:complexType name="ServiceProviderType">
<xsd:annotation>
<xsd:documentation>Complex type for the service provider</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element ref="ServiceUri"/>
<xsd:element ref="ServiceProviderName"/>
</xsd:sequence>
<xsd:anyAttribute namespace="##any" processContents="lax"/>
</xsd:complexType>
The URI can point to the XML structure defined by the OASIS CIQ
specification.
The name and address of the party is not defined in the BSLA schema.
Since it is too late to do major change on schema, it is proposed to close
this issue with no action.
Proposal 22009-06-24
Rex: Similar, could lead to a change. We should review the CIQ specification for parties. In SLA we're defining parties, not only name and address. Reusing an existing OASIS Committee Specification. I've already used it in Emergency Management. It's not perfect, but it's moving toward a standard for these issues. They've already vetted it. CIQ originally stood for "Customer Information Quality", not it's "Party Information Quality" - as in the parties to SLAs which can be an individual, a group, a corporation, a government - the specification handles all of those. I suggest importing the schema for CIQ.
Bill: The issue I see is overlap with UBL, which is an OASIS standard.
Zhili: CIQ is not an OASIS standard at this time.
Szu: No need to use name and address for SLA schema now; propos to defer.
Rex: Consider for other of the TC's specifications as well.
Action: i025 Keep Open, but defer to next CD. That is this issue will be addressed after CD02.
Proposal 3 2009-09-02
Per TC meeting on 09/02/2009, mark it to defer to post CD02. This issue will be addressed after CD02.
|
Task
|
i023 Rating Issue: QualityAssertionEvaluation
|
SOAEERP-40
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Won't Fix
|
23/Jun/10 12:17 AM
|
01/Sep/10 08:58 PM
|
|
|
(Note: I'll repeat this intro where it applies to the issues I bring
up.) I have not had time to address these specs as I would have
preferred, but as I am working through the process of diagramming the
SOA Reference Architecture Foundation due to be released for Public
Review in July (hopefully), I do have time to bring up a few
crossover issues that will help align and coordinate the use of the
RAF to develop specific, concrete solution architectures.
This Issue applies to the Rating Specification for the Performance category.
This element is the mechanism for Service Rating Entities to provide
their evaluation for how well Service Providers fulfill the
QualityAssertion(s) of their service(s). As with my suggestion for
BQoS:Performance:QualityAssertion, this Evaluation element is
something that I expect will evolve over time, and I don't have
suggestions at this time for specific subcategories of
QualityAssestionEvaluation. I think it would be wise to include this
as a free text element at first. Later we may have subcategories that
arise, but I wouldn't want to wait until we define those in order to
get feedback from our audience on what they want to assert and how
they want assertions evaluated.
For instance, when a conference management service asserts: "We
deliver a high percentage of decision makers and decision
influencers," this assertion can be evaluated by a rating service to
say something like, "Acme Conference Management's delivery of
decision makers and decison influencers at 35% for Conference X
prompts our rating of poor for this assertion."
Because many Quality Assertions and Evaluations may be subjective
(e..g. "a good time will be had by all"), the compilation of attendee
surveys using equally subjective assessments provides a somewhat more
objective basis for ratings services to evaluate quality assertions.
Without the mechanisms for assertion and evaluation, these ratings
would be more purely subjective and less valuable for potential
service consumers.
By providing Service Providers with a BQoS:
Performance:QualityAssertion, and Service Ratings Firms with a
QualiftyAssertionEvaluation, I think we can begin to make better
assessments of services.
Cheers,
Rex
Raised against / Related drafts
EERP-Rating revision: WD05
Justification
N/A
Related Issues
Origin
Rex Brooks
Owner
Szu Chang
|
Proposal 1 2009-06-24
SOA_EERP Business Rating spec version 1.0 Working Draft 06 (WD06) uploaded
at
http://www.oasis-open.org/committees/download.php/33070/BusinessRating-v1.0-spec-wd06.pdf
It fixed this issue on line # 98-101 and 137 -140.
It is proposed to close the issue with above changes.
Proposal 2 2009-06-24
Rex: In i022 in BQOS we need to provide a set of quality-performance assertions. Under rating, anyone should be able to use the BQOS specification, take whatever a service provide states (as an assertion) and evaluate it. This lends itself to making forms rather than long, rambling text descriptions—forms with boxes to check are much easier to work with.
Action: i023 Keep open (as for i022) and defer to next CD. This issue will be addressed after CD02.
Proposal 3 2009-09-02
Per TC meeting on 09/02/2009, mark it to defer to post CD02. This issue will be addressed after CD02.
|
Task
|
i022 Performance:QualityAssertion
|
SOAEERP-39
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
23/Jun/10 12:14 AM
|
15/Sep/10 09:13 PM
|
|
This issue is discussed on 06/23/2010's TC meeting, with:
Current WD09 @ http://www.oasis-open.org/committees/download.php/38435/SOA-EERP-bQoS-Specwd09-diff-cd03.pdf has the following (Line 337 to 344):
[18:34] /bqos:BQoS/bqos:BQoSQualities/bqosropertyName
338 Property name is a required element for the name in the name and value pair in the Property
339 element. It uses bqosropertyNameType which is a cbc:NamType from UBL that has a optional
340 languageID attribute for language code.
[18:34] /bqos:BQoS/bqos:BQoSQualities/bqosroperty/bqosropertyValue
349 The property value is an optional element for the value in the name and value pair in the Property
350 element. It uses bqosropertyValueType which is a cbc:NamType from UBL that has a optional
351 languageID attribute for language code.
You can put any name-value onto BQoSQualities.
While any quality name/value can be asserted by a Service Provider, there are three pre-defined names, one of which (bQOSPrice) is mandatory. We are not addressing issues of namespace management for qualities beyond the three pre-defined qualities.
The following text is added to BQoS spec at http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/39310/SOA-EERP-bSLA-Spec-cd04.pdf:
444 The BQoSQualities, the Quality elements for bQoS, describes additional properties and attributes for the
445 service. While any quality name/value can be asserted by a Service Provider to represent the quality of
446 the service, this specification is not addressing issues of namespace management for qualities beyond
447 the three pre-defined EERP namespaces.
[ Show » ] Szu Chang added a comment - 15/Sep/10 03:39 PM The following text is added to BQoS spec at http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/39310/SOA-EERP-bSLA-Spec-cd04.pdf: 444 The BQoSQualities, the Quality elements for bQoS, describes additional properties and attributes for the 445 service. While any quality name/value can be asserted by a Service Provider to represent the quality of 446 the service, this specification is not addressing issues of namespace management for qualities beyond 447 the three pre-defined EERP namespaces.
|
Hi Everyone,
(Note: I'll repeat this intro where it applies to the issues I bring
up.) I have not had time to address these specs as I would have
preferred, but as I am working through the process of diagramming the
SOA Reference Architecture Foundation due to be released for Public
Review in July (hopefully), I do have time to bring up a few
crossover issues that will help align and coordinate the use of the
RAF to develop specific, concrete solution architectures.
This Issue applies to the BQoS Specification for the Performance category.
I think we should include a formal mechanism for Service Providers to
assert the specific Qualities of their services. Because this is
something that I expect will evolve over time, I don't have
suggestions at this time for specific subcategories of Quality. I
think it would be wise to include this as a free text element at
first. Later we may have subcategories that arise, but I wouldn't
want to wait until we define those in order to get feedback from our
audience on what they want to assert about their services.
For instance, a conference management service might assert: "We
deliver a high percentage of decision makers and decision
influencers." This kind of assertion sets the foundation for a rating
service to say something like, "Acme Conference Management delivered
an audience for Conference X in which only 35% of attendees could be
confirmed as decision makers."
Because many Quality Assertions may be subjective (e..g. "a good time
will be had by all"), without such an assertion, rating services and
potential Service Consumers will not have a basis against which to
evaluate services. The point is that even subjective Quality
Assertions can be evaluated by ratings services, even if we can
assign an objective unit of measure.
By providing Service Providers with a BQoS:
Performance:QualityAssertion, I think we can begin to make better
assessments of services.
Cheers,
Rex
Raised against / Related drafts
EERP-bQoS revision: WD04
Justification
N/A
Related Issues
Origin
Rex Brooks
Owner
Szu Chang
|
Proposal 1 2009-06-24
SOA-EERP BusinessQualityOfService-v1.0-spec-WD05 is uploaded at
http://www.oasis-open.org/committees/download.php/33062/BusinessQualityOfService-v1.0-spec-wd05.doc
It fixed this issue on line # 329-331.
It is proposed to close the issue with above changes.
Proposal 2 2009-06-24
Szu: We probably will not change the schemas, as we've already reviewed them. This is put to any element of quality.
Rex: This is only intended to be the first of what I expect to be several such issues; I hope that others on the TC will think about the kinds of assertions. Bill: Name-Value pairs have similar issues.Rex:
Action: i022 Keep open.
Bill suggested we defer decisions on whether a fix goes into CD02, a WD, or some other versions; then we'll go back through. Our current target is a new WD that can become Committee Draft 02.
Proposal 3 2009-09-02
Per TC meeting on 09/02/2009, mark it to defer to post CD02. This issue will be addressed after CD02.
|
Task
|
Issue with URIs and how an implementation can distinguish them
|
SOAEERP-38
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
10/Jun/10 05:08 AM
|
01/Sep/10 09:04 PM
|
|
|
The reference to services and other things are all URIs. How can an implementation determine which kind of service or entity is at the URI used? This is in all three information specifications
WTC: The key issue is how can the nature of something referenced by a URI be determined, e.g. is it a rating service? Is another service?
|
|
Sub-task
|
SOAEERP-6
PR07-T16 Issue with URIs and how an implementation can distinguish them
|
SOAEERP-37
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 05:37 AM
|
01/Sep/10 09:33 PM
|
|
|
17. the reference to services and other things are all URIs. How can an implementation determine which kind of service or entity is at the URI used? This is in all three specifications.
|
No change. Up to implementations using this information model.
|
Sub-task
|
SOAEERP-6
PR07-T15 BSLA Table 1 should reference both UBL and CEFAACT
|
SOAEERP-36
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 05:26 AM
|
01/Sep/10 09:39 PM
|
|
All minor editorial comments on this issue are resolved. The issue is closed.
|
16. BSLA table 1, udt - why does this referenc both UBL and CEFAACT when it's a urn to CEFACT?
|
Changes are in WD09 :
http://www.oasis-open.org/committees/download.php/38435/SOA-EERP-bQoS-Specwd09-diff-cd03.pdf
Line 115, table 1
http://www.oasis-open.org/committees/download.php/38432/SOA-EERP-bSLA-spec-wd09-diff-cd03.pdf
Line 122, Table 1
http://www.oasis-open.org/committees/download.php/38429/SOA-EERP-bRating-Spec-wd09-diff-cd03.pdf
Line 98, table 1
|
Sub-task
|
SOAEERP-6
PR07-T14 Common words are not defined in three specifications
|
SOAEERP-35
|
William Cox
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 05:23 AM
|
01/Sep/10 09:05 PM
|
|
|
15. All three specifications use common words (e.g. Service, SLA, Quality of Service, Rating, Credentials) but do not define them or reference the relevant definitions. All the specifications should carefully compare and conrast, and where a specific technical meaning or meaning may be understood, indicate whether that meaning is intended. Otherwise the documents are hard to comprehend. The missing comparison and contast beteween "SLA" and "BSLA" is one case in point (see item 14). The connections all need to be explicit, not implicit or suggested (but never confirmed). The documents read as if there were a detailed architectural and interaction model that is understood by the authors but never explained to the readers. This is a barrier to implementation, understanding, and conformance.
|
New revision on WD09:
Whitepaper line 161 - 180 of http://www.oasis-open.org/committees/download.php/38426/EERP-Model-UseCase-WhitePaper-wd09-diff-cd03-withLineNumber.pdf
161 Business Quality of Service (bQoS) models the business characteristics of a service for
162 estimating the business value of one or a set of services in a business process. In
163 contrast to the QoS in the software/IT world, where the message is network/system
164 oriented measurement that deals with network performance and system availability, the
165 contents of bQoS in this specification is business oriented measurement that deals with
166 business characteristics of a service, such as price, performance, and quality.
167 Business Rating (bRating) defines credibility, reliability and reputation of the service
168 need to be understood for estimating the overall business quality of the process that uses
169 those services. It has two major kinds of rating: Rating and Credentials. Rating are
170 provided by the rating provider to show the ranking and reputation of a given service
171 provider, in comparison of other providers. In contrast, Credentials are provided by the
172 service provider itself to show the credibility of providing a given service.
173 Business Service Level Agreement (bSLA) is the agreement between the service
174 requestor and the service provider, and primary address the bQoS content, Rating and
175 Credentials. These contents are all business related. In contrast to the SLA (Service Level
176 Agreement) in the software/IT world, where SLA is the contract between the service
177 provider and the network/system provider, and the SLA is network/system oriented
178 agreement that deals with network performance and system availability. The bSLA in the
179 EERP is business oriented agreement that deals with price, time to deliver, and the
180 quality/rating of the service.
bQoS spec http://www.oasis-open.org/committees/download.php/38435/SOA-EERP-bQoS-Specwd09-diff-cd03.pdf
Line 21 -24
21 In contrast to the QoS in the software/IT world, where the message is network/system oriented
22 measurement indicates that deals with network performance and system availability, the contents of
23 bQoS in this specification is business oriented measurement indicators that deals with business
24 characteristics of a service, such as price, performance, and quality.
bRating spec http://www.oasis-open.org/committees/download.php/38429/SOA-EERP-bRating-Spec-wd09-diff-cd03.pdf
Line 161-164:
161 The ListOfRating element contains the list of Rating issued by a Rating Provider. The Rating Provider is a
162 party unaffiliated with either the requester or the target of the rating request, such as a third party rating
163 organization, given a reference to a particular business service and provider, issues either a number or a
164 classification description for rating.
bSLA spec http://www.oasis-open.org/committees/download.php/38432/SOA-EERP-bSLA-spec-wd09-diff-cd03.pdf
Line 24-29:
24 The bSLA is different than the SLA (Service Level Agreement) in the software/IT world. The bSLA in this
25 specification is the contact between the service requester and the service provider. The bSLA in this
26 specification is the contact between the service requester and the service provider, and the SLA is the
27 contract between the service provider and the network/system provider. The SLA is network/system
28 oriented agreement that deals with network performance and system availability. The bSLA is a business
29 oriented agreement that deals with price, time to deliver, and the quality/rating of the service.
[ Show » ] Szu Chang added a comment - 23/Jun/10 06:36 PM New revision on WD09: Whitepaper line 161 - 180 of http://www.oasis-open.org/committees/download.php/38426/EERP-Model-UseCase-WhitePaper-wd09-diff-cd03-withLineNumber.pdf 161 Business Quality of Service (bQoS) models the business characteristics of a service for 162 estimating the business value of one or a set of services in a business process. In 163 contrast to the QoS in the software/IT world, where the message is network/system 164 oriented measurement that deals with network performance and system availability, the 165 contents of bQoS in this specification is business oriented measurement that deals with 166 business characteristics of a service, such as price, performance, and quality. 167 Business Rating (bRating) defines credibility, reliability and reputation of the service 168 need to be understood for estimating the overall business quality of the process that uses 169 those services. It has two major kinds of rating: Rating and Credentials. Rating are 170 provided by the rating provider to show the ranking and reputation of a given service 171 provider, in comparison of other providers. In contrast, Credentials are provided by the 172 service provider itself to show the credibility of providing a given service. 173 Business Service Level Agreement (bSLA) is the agreement between the service 174 requestor and the service provider, and primary address the bQoS content, Rating and 175 Credentials. These contents are all business related. In contrast to the SLA (Service Level 176 Agreement) in the software/IT world, where SLA is the contract between the service 177 provider and the network/system provider, and the SLA is network/system oriented 178 agreement that deals with network performance and system availability. The bSLA in the 179 EERP is business oriented agreement that deals with price, time to deliver, and the 180 quality/rating of the service. bQoS spec http://www.oasis-open.org/committees/download.php/38435/SOA-EERP-bQoS-Specwd09-diff-cd03.pdf Line 21 -24 21 In contrast to the QoS in the software/IT world, where the message is network/system oriented 22 measurement indicates that deals with network performance and system availability, the contents of 23 bQoS in this specification is business oriented measurement indicators that deals with business 24 characteristics of a service, such as price, performance, and quality. bRating spec http://www.oasis-open.org/committees/download.php/38429/SOA-EERP-bRating-Spec-wd09-diff-cd03.pdf Line 161-164: 161 The ListOfRating element contains the list of Rating issued by a Rating Provider. The Rating Provider is a 162 party unaffiliated with either the requester or the target of the rating request, such as a third party rating 163 organization, given a reference to a particular business service and provider, issues either a number or a 164 classification description for rating. bSLA spec http://www.oasis-open.org/committees/download.php/38432/SOA-EERP-bSLA-spec-wd09-diff-cd03.pdf Line 24-29: 24 The bSLA is different than the SLA (Service Level Agreement) in the software/IT world. The bSLA in this 25 specification is the contact between the service requester and the service provider. The bSLA in this 26 specification is the contact between the service requester and the service provider, and the SLA is the 27 contract between the service provider and the network/system provider. The SLA is network/system 28 oriented agreement that deals with network performance and system availability. The bSLA is a business 29 oriented agreement that deals with price, time to deliver, and the quality/rating of the service.
|
Sub-task
|
SOAEERP-6
PR07-T13 Compare and contrast BSLA and SLA in the software/IT world
|
SOAEERP-34
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 05:20 AM
|
01/Sep/10 09:40 PM
|
|
|
14. BSLA lines 1-12. This is not sufficient to connect the notion of a BUSINESS Service Level Agreement to an SLA as understood in the software/IT world. An explanation connecting, contrasting, and comparing the notoins should be included. There is some defition in 2.3 (line 108-110) which partially satisfies this. In conjunction with comment 15 this needs to be more clear and more prominently placed at the beginning of the document in Section 1.
|
Changed make on WD09 of http://www.oasis-open.org/committees/download.php/38432/SOA-EERP-bSLA-spec-wd09-diff-cd03.pdf
Line 24-29 with the following:
24 The bSLA is different than the SLA (Service Level Agreement) in the software/IT world. The bSLA in this
25 specification is the contact between the service requester and the service provider. The bSLA in this
26 specification is the contact between the service requester and the service provider, and the SLA is the
27 contract between the service provider and the network/system provider. The SLA is network/system
28 oriented agreement that deals with network performance and system availability. The bSLA is a business
29 oriented agreement that deals with price, time to deliver, and the quality/rating of the service.
White paper http://www.oasis-open.org/committees/download.php/38426/EERP-Model-UseCase-WhitePaper-wd09-diff-cd03-withLineNumber.pdf
Line 173-180 with the following:
173 Business Service Level Agreement (bSLA) is the agreement between the service
174 requestor and the service provider, and primary address the bQoS content, Rating and
175 Credentials. These contents are all business related. In contrast to the SLA (Service Level
176 Agreement) in the software/IT world, where SLA is the contract between the service
177 provider and the network/system provider, and the SLA is network/system oriented
178 agreement that deals with network performance and system availability. The bSLA in the
179 EERP is business oriented agreement that deals with price, time to deliver, and the
180 quality/rating of the service.
|
Sub-task
|
SOAEERP-6
PR07-T12 Non-normative text in BSLA should be identified.
|
SOAEERP-33
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 05:18 AM
|
01/Sep/10 09:38 PM
|
|
Text changes are on WD09 of bSLA spec at http://www.oasis-open.org/committees/download.php/38432/SOA-EERP-bSLA-spec-wd09-diff-cd03.pdf.
No more issues on this minor editorial comments.
|
13. In BSLA Non-Normative text is Appendix C, preceded by the SML Schema. This should be identified per OASIS rules as non-normative and that the separate XSD file is normative.
|
Same as SAO-EERP-28, changes on bSLA spec on WD09 at http://www.oasis-open.org/committees/download.php/38432/SOA-EERP-bSLA-spec-wd09-diff-cd03.pdf
bSLA spec: Line 672, 860-861
672 The examples in this section are non-normative.
860 Note: The separate machine readable schema document, listed on Section 2.2, is normative. The text
861 included here is non-normative.
|
Sub-task
|
SOAEERP-6
PR07-T11 The term "Credentials" is not well defined in the Rating spec.
|
SOAEERP-32
|
Szu Chang
|
Paul Yang
|
Minor
|
Closed
|
Fixed
|
13/May/10 05:14 AM
|
01/Sep/10 09:37 PM
|
|
|
12. In Rating, not enough is done to connect "Credentials" to the common uses of the term, including in security and business. This is essential.
|
"(WTC) include Rating Credentials as a defined term. Replace all uses of "credential(s) with "Rating Credential(s)".
Define the term as follows:
Rating Credentials include but are not limited to licenses, permissions, certifications, awards, associations, degrees, quality descriptions, and affiliations. They describe a specific service or set of services by a particular service provider.*
*Rating Credentials are distinct from security credentials, although the core meaning is related. Rating Credentials suggest the value or quality of a given service offered by a service provider. [FOOTNOTE TO DEFINITION]
|
Sub-task
|
SOAEERP-6
PR07-T10 Non-normative text is not identified
|
SOAEERP-31
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 05:12 AM
|
01/Sep/10 09:36 PM
|
|
Text changes are on WD09 of bQoS spec at http://www.oasis-open.org/committees/download.php/38435/SOA-EERP-bQoS-Specwd09-diff-cd03.pdf
Text changes are on WD09 of bRating spec at http://www.oasis-open.org/committees/download.php/38429/SOA-EERP-bRating-Spec-wd09-diff-cd03.pdf
Text changes are on WD09 of bSLA spec at http://www.oasis-open.org/committees/download.php/38432/SOA-EERP-bSLA-spec-wd09-diff-cd03.pdf.
No more issues on this minor editorial comments.
|
11. Again in Rating, line 624 (and similar locations in the other specs): OASIS specifies that the normative schema is that in the identified separate file. This should be noted in all of the schema in the specifications. In (e.g.) bQoS, Appendix B "Non-Normative Text" says "none" but is followed by non-normative Appendix C which is not identified as non-normative.
|
Same as issue SOA-EERP-28, changed on WD09, including http://www.oasis-open.org/committees/download.php/38435/SOA-EERP-bQoS-Specwd09-diff-cd03.pdf , http://www.oasis-open.org/committees/download.php/38432/SOA-EERP-bSLA-spec-wd09-diff-cd03.pdf and http://www.oasis-open.org/committees/download.php/38429/SOA-EERP-bRating-Spec-wd09-diff-cd03.pdf
Added "non-normative" to the examples, and Appendix B.
>> BQoS spec: Line 379, 522-523
379 The examples in this section are non-normative.
522 Note: The separate machine readable schema document, listed on Section 2.2, is normative. The text
523 included here is non-normative.
http://www.oasis-open.org/committees/download.php/38435/SOA-EERP-bQoS-Specwd09-diff-cd03.pdf
>> Rating spec: Line 460, 645-646
460 The examples in this section are non-normative.
645 Note: The separate machine readable schema document, listed on Section 2.2, is normative. The text
646 included here is non-normative.
http://www.oasis-open.org/committees/download.php/38429/SOA-EERP-bRating-Spec-wd09-diff-cd03.pdf
>> BSLA spec: Line 672, 860-861
672 The examples in this section are non-normative.
860 Note: The separate machine readable schema document, listed on Section 2.2, is normative. The text
861 included here is non-normative.
|
Sub-task
|
SOAEERP-6
PR07-T9 The term "third party" in the Business Rating spec is problematic
|
SOAEERP-30
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 05:05 AM
|
04/Aug/10 09:48 PM
|
|
All changes are in WD09 as they are referenced http://www.oasis-open.org/committees/download.php/38429/SOA-EERP-bRating-Spec-wd09-diff-cd03.pdf
|
10. The use of "third party" (e.g., in Rating lines 100) is problematic. Does the specification assert that only "third parties", which is taken to mean "parties unaffiliated with either the requester or the target of the rating request" will respond? The conformance clauses on this issue are extremely weak. This is another area where the overall architecture, in a normative form rather than a white paper, is essential to understanding.
|
Conformance for bRating spec changed on WD09, http://www.oasis-open.org/committees/download.php/38429/SOA-EERP-bRating-Spec-wd09-diff-cd03.pdf, as the following:
Line 589-615.
589 The minimum set of information exchange for Business Rating that would allow conforming applications
590 to exchange information and satisfy the conformance should have either
591 /rt:BRating/rt:ListOfRating/rt:Rating/rt:RatingIssuer/rt:IssuerUri element or
592 /rt:BRating/rt:Credentials/rt:Credential/rt:CredentialIssuer/rt:IssuerUri element, like this:
593 (001) <?xml version="1.0" encoding="utf-8"?>
594 (002) <BRating xmlns="http://docs.oasis-open.org/ns/soa-eerp/rt/200903">
595 (003) <ListOfRating>
596 (004) <Rating>
597 (005) <RatingIssuer>
598 (006) <IssuerUri>http://www.sample-rating-issuer.org</IssuerUri>
599 (007) </RatingIssuer>
600 (008) . . .
601 (009) </Rating>
602 (010) </ListOfRating>
603 (011) </BRating>
604 Or like this:
605 (001) <?xml version="1.0" encoding="utf-8"?>
606 (002) <BRating xmlns="http://docs.oasis-open.org/ns/soa-eerp/rt/200903">
607 (003) <Credentials>
608 (004) <Credential>
609 (005) <CredentialIssuer>
610 (006) <IssuerUri>httphttp://www.sample-cred-issuer.com</IssuerUri>
611 (007) </CredentialIssuer>
612 (008) . . .
613 (009) </Credential>
614 (010) </Credentials>
615
|
Sub-task
|
SOAEERP-6
PR07-T8 Whitepaper does not define an architecture for interaction
|
SOAEERP-29
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 05:02 AM
|
01/Sep/10 09:35 PM
|
|
|
9. The White paper does not carefully define a model or architecture for interaction; those aspects of EERP should be spelled out in the forthcoming protocol specification. Some may be better in these specifications, e.g., could it be stated that only a rating service returns a rating list? and only a business service (still undefined) returns credentials?
|
The service definitions for exchanging the artifacts in CD04 will be in the Protocol Spec.
The definitions and relationships of actors (e.g., what is a rating service provider? is it a service as in the services that have bSLA?) must be in that component.
No change. The white paper addresses this, and the incomplete Protocol spec also addresses this.
|
Sub-task
|
SOAEERP-6
PR07-T7 Include a non-normative section in each specification
|
SOAEERP-28
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 05:00 AM
|
04/Aug/10 09:47 PM
|
|
Changes were made, no more actions for this issue. Also boilerplate says examples are non-normative.
|
8. A non-normative section should be included in each specification showing additional samples, and demonstrating that empty or nearly empty artifacts do not conform.
|
Added "non-normative" to the examples, and Appendix B.
>> BQoS spec: Line 379, 522-523
379 The examples in this section are non-normative.
522 Note: The separate machine readable schema document, listed on Section 2.2, is normative. The text
523 included here is non-normative.
http://www.oasis-open.org/committees/download.php/38435/SOA-EERP-bQoS-Specwd09-diff-cd03.pdf
>> Rating spec: Line 460, 645-646
460 The examples in this section are non-normative.
645 Note: The separate machine readable schema document, listed on Section 2.2, is normative. The text
646 included here is non-normative.
http://www.oasis-open.org/committees/download.php/38429/SOA-EERP-bRating-Spec-wd09-diff-cd03.pdf
>> BSLA spec: Line 672, 860-861
672 The examples in this section are non-normative.
860 Note: The separate machine readable schema document, listed on Section 2.2, is normative. The text
861 included here is non-normative.
http://www.oasis-open.org/committees/download.php/38432/SOA-EERP-bSLA-spec-wd09-diff-cd03.pdf
|
Sub-task
|
SOAEERP-6
PR07-T6 Relationshiop between SOA and SOARM is not stated in BSLA
|
SOAEERP-27
|
William Cox
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 04:23 AM
|
01/Sep/10 09:11 PM
|
|
|
7. Likewise, "Business Service Level Agreement" suggests a relationship to SOA-and SOA RM, but the relationship is never stated.
|
bSLA spec has the following:
6 According to OASIS Reference Model for Service Oriented Architecture [SOA-RM], Service Oriented
7 Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the
8 control of different ownership domains. The service within SOA is a mechanism to enable access to one
9 or more capabilities, where the access is provided using a prescribed interface and is exercised
10 consistent with constraints and policies as specified by the service description. This specification further
11 defines the bSLA between the service requester and the service provider for the service which is defined
12 in SOA-RM, within the EERP technology.
|
Sub-task
|
SOAEERP-6
PR07-T5 Soa meaning is implied, but is never stated.
|
SOAEERP-26
|
William Cox
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 04:22 AM
|
01/Sep/10 09:13 PM
|
|
|
6. The tiles of the specs and the TC strongly suggest that the Soa meaning is implied, but is never stated.
|
For wxample, bQoS spec has the following:
6 According to OASIS Reference Model for Service Oriented Architecture [SOA-RM], Service Oriented
7 Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the
8 control of different ownership domains. The service within SOA is a mechanism to enable access to one
9 or more capabilities, where the access is provided using a prescribed interface and is exercised
10 consistent with constraints and policies as specified by the service description. This specification further
11 defines the Business Quality of Service for the services that is defined in SOA-RM, within the EERP
12 technology.
|
Sub-task
|
SOAEERP-6
PR07-T4 The term "Service" is not defined or referenced.
|
SOAEERP-25
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 04:21 AM
|
17/Sep/10 06:13 AM
|
|
Yulin has updated WD10 to address three outstanding issues together:
http://tools.oasis-open.org/issues/browse/SOAEERP-8
http://tools.oasis-open.org/issues/browse/SOAEERP-22
http://tools.oasis-open.org/issues/browse/SOAEERP-25
The changes are:
bQoS Spec WD10 @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/document.php?document_id=39238, Line 141-142
bRating Spec WD10 @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/document.php?document_id=39239, Line 141-142
bSLA Spec WD10 @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/document.php?document_id=39240, Line 148-149
White paper WD10 @ , http://www.oasis-open.org/apps/org/workgroup/soa-eerp/document.php?document_id=39237, on page 5, Introduction section, second paragraph, added the following text:
In this context, a service is a component capable of performing a task, or a type of capability described using WSDL, while SOA is referred to by W3C (World Wide Web Consortium) as a set of components which can be invoked, and whose interface descriptions can be published and discovered. The applications of these three specifications are any kind of business services, and they are not limited to only Web Services.
The above changes then have incorporated into WD11 for the candidate of CD04. They are:
bQoS spec @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/39374/SOA-EERP-bQoS-Spec-wd11.pdf
138 ... The applications of this specification are any kind of business services, and they are not
139 limited to only Web Services.
bRating spec @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/39379/SOA-EERP-bRating-Spec-wd11.pdf
135 ... The applications of this specification
136 are any kind of business services, and they are not limited to only Web Services.
bSLA Spec @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/39377/SOA-EERP-bSLA-Spec-wd11.pdf
150 ... The applications of this specification are any kind of business
151 services, and they are not limited to only Web Services.
White paper WD11 @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/39370/EERP-Model-UseCase-WhitePaper-wd11.pdf, page 5, second paragraph, whole section
|
5. bqOs lines 5ff: a service is not defined in this specification, yet "service discovery" is applied. All uses of service must be examined for consistency with the "service" in Service Oriented Architecture. "Business Service" is a new definition in these specs and should be carefully and clearly defined. This comment applies to all of the specifications -- service is used frequently but not defined and without reference to SOA-RM.
|
In addtion of >> Changes on the following:
>> White paper: page 5, the third section
http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/37833/EERP-Model-UseCase-WhitePaper-cd03-diff-wd08withLineNumber.pdf
>> BQoS spec: Line 5-12
http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/37750/SOA-EERP-bQoS-Spec-cd03-diff-wd08.doc
>> Rating spec: Line 12
http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/37739/SOA-EERP-Rating-Spec-cd03-diff-wd08.doc
>> BSLA spec: Line 13
http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/37743/SOA-EERP-BSLA-spec-cd03-diff-wd08.doc
Add the following text to three specs:
"The applications of this specification are any kind of business services, and they are not limited to only Web Services."
And add the following text to the white paper:
"In this context, a service is a component capable of performing a task, or a type of capability described using WSDL, while SOA is referred to by W3C (World Wide Web Consortium) as a set of components which can be invoked, and whose interface descriptions can be published and discovered. The applications of these three specifications are any kind of business services, and they are not limited to only Web Services."
|
Sub-task
|
SOAEERP-6
PR07-T3 Consistency of the Services and Service Providers Identities
|
SOAEERP-24
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 04:20 AM
|
04/Aug/10 09:46 PM
|
|
The details of service URI will be addressed on the protocol spec. This issue is closed.
|
4. The TC should consider whether the details of how services and service providers are identified is consistent with good practices in defining information exchanges. In other words, these specifications may need to change due to design considerations for the protocol, which is not being reviewed at this time. A review with a future version of these specifications and the protocol should undergo a unified public review in the future.
|
Refer to issue SOA-EERP-37, http://tools.oasis-open.org/issues/browse/SOAEERP-37, the service URI will be addressed on the protocol spec.
Issues around the services will be addressed on SOAEERP-22 and SOAEERp-25.
There are no schema changes for these three specs: bQoS, bRating, and bSLA, from CD03 to WD09, and the XML Schema of EERP protocol as it is stated in the EERP protocol WD03, per http://www.oasis-open.org/apps/org/workgroup/soa-eerp/document.php?document_id=37452 will have no changes needed for XML schema of three specs: bQoS, bRating, and bSLA.
[ Show » ] Szu Chang added a comment - 23/Jun/10 08:16 PM Refer to issue SOA-EERP-37, http://tools.oasis-open.org/issues/browse/SOAEERP-37, the service URI will be addressed on the protocol spec. Issues around the services will be addressed on SOAEERP-22 and SOAEERp-25. There are no schema changes for these three specs: bQoS, bRating, and bSLA, from CD03 to WD09, and the XML Schema of EERP protocol as it is stated in the EERP protocol WD03, per http://www.oasis-open.org/apps/org/workgroup/soa-eerp/document.php?document_id=37452 No changes anticipated for XML schema of three specs: bQoS, bRating, and bSLA.
|
Sub-task
|
SOAEERP-6
PR07-T2 Reopen and Reconsider "Deferred" Issues
|
SOAEERP-23
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 04:19 AM
|
04/Aug/10 09:43 PM
|
|
New issues are opened.
|
3. All issues identified as "Deferred" in the TC issues list dated 2009-10-24 Revision 18 should be opened and considered.
|
Open new issues.
|
Sub-task
|
SOAEERP-6
PR07-T1 Terminology Inconsistency
|
SOAEERP-22
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 04:18 AM
|
17/Sep/10 06:19 AM
|
|
Yulin has updated WD10 to address three outstanding issues together:
http://tools.oasis-open.org/issues/browse/SOAEERP-8
http://tools.oasis-open.org/issues/browse/SOAEERP-22
http://tools.oasis-open.org/issues/browse/SOAEERP-25
The changes are:
bQoS Spec WD10 @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/document.php?document_id=39238, Line 141-142
bRating Spec WD10 @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/document.php?document_id=39239, Line 141-142
bSLA Spec WD10 @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/document.php?document_id=39240, Line 148-149
White paper WD10 @ , http://www.oasis-open.org/apps/org/workgroup/soa-eerp/document.php?document_id=39237, on page 5, Introduction section, second paragraph, added the following text:
In this context, a service is a component capable of performing a task, or a type of capability described using WSDL, while SOA is referred to by W3C (World Wide Web Consortium) as a set of components which can be invoked, and whose interface descriptions can be published and discovered. The applications of these three specifications are any kind of business services, and they are not limited to only Web Services.
The above changes then have incorporated into WD11 for the candidate of CD04. They are:
bQoS spec @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/39374/SOA-EERP-bQoS-Spec-wd11.pdf
138 ... The applications of this specification are any kind of business services, and they are not
139 limited to only Web Services.
bRating spec @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/39379/SOA-EERP-bRating-Spec-wd11.pdf
135 ... The applications of this specification
136 are any kind of business services, and they are not limited to only Web Services.
bSLA Spec @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/39377/SOA-EERP-bSLA-Spec-wd11.pdf
150 ... The applications of this specification are any kind of business
151 services, and they are not limited to only Web Services.
White paper WD11 @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/39370/EERP-Model-UseCase-WhitePaper-wd11.pdf, page 5, second paragraph, whole section
|
1. The terminology appears to be inconsistent with that in the SOA Reference Model. Terminology alignment with that specification. This applies to the White Paper, and the explanatory sections of all three specification. In particular, at least the use of "Service" should be made consistent in all SOA-EERP specifications.
|
In addition to the following:
>> Changes carried forward and fixed problems onto WD09:
>> White paper: Page 5, line 93-112
http://www.oasis-open.org/committees/download.php/38426/EERP-Model-UseCase-WhitePaper-wd09-diff-cd03-withLineNumber.pdf
>> BQoS spec: Line 6-12
http://www.oasis-open.org/committees/download.php/38435/SOA-EERP-bQoS-Specwd09-diff-cd03.pdf
>> Rating spec: Line 5-10
http://www.oasis-open.org/committees/download.php/38429/SOA-EERP-bRating-Spec-wd09-diff-cd03.pdf
>> BSLA spec: Line 6-12
http://www.oasis-open.org/committees/download.php/38432/SOA-EERP-bSLA-spec-wd09-diff-cd03.pdf
It is proposed to add the following text to three specs:
"The applications of this specification are any kind of business services, and they are not limited to only Web Services."
And add the following text to the white paper:
"In this context, a service is a component capable of performing a task, or a type of capability described using WSDL, while SOA is referred to by W3C (World Wide Web Consortium) as a set of components which can be invoked, and whose interface descriptions can be published and discovered. The applications of these three specifications are any kind of business services, and they are not limited to only Web Services."
|
Sub-task
|
SOAEERP-6
PR07-E1 right hand (recto) page vs. left hand (verso) page
|
SOAEERP-21
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 04:16 AM
|
04/Aug/10 09:29 PM
|
|
Editorial changes applied.
|
2. Editorial: Many sections start on a left hand (verso) page. They should start on a right hand (recto) page.
|
Fixed in all 4 WD09 documents, see the following:
http://www.oasis-open.org/committees/download.php/38435/SOA-EERP-bQoS-Specwd09-diff-cd03.pdf
http://www.oasis-open.org/committees/download.php/38432/SOA-EERP-bSLA-spec-wd09-diff-cd03.pdf
http://www.oasis-open.org/committees/download.php/38429/SOA-EERP-bRating-Spec-wd09-diff-cd03.pdf
http://www.oasis-open.org/committees/download.php/38426/EERP-Model-UseCase-WhitePaper-wd09-diff-cd03-withLineNumber.pdf
This issue to be verified and closed.
|
Sub-task
|
SOAEERP-7
PR08-T4 SOA-EERP-BSLA-spec-cd03.pdf
|
SOAEERP-20
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 04:07 AM
|
15/Sep/10 09:17 PM
|
|
Requires delivery and approval of CD04. Needs to be applied as part of publication of that CD as a public review document.
|
'* Line 106: Incorrect url:
http://docs.oasis-open.org/soa-eerp/eerp-sla/200903/eerp-sla.xsd
Current Correct Link:*
http://docs.oasis-open.org/soa-eerp/sla/v1.0/EERP-SLA-cd03.xsd*
|
|
Sub-task
|
SOAEERP-7
PR08-T3 SOA-EERP-Rating-Specification.pdf
|
SOAEERP-19
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 04:05 AM
|
15/Sep/10 09:19 PM
|
|
Requires delivery and approval of CD04. Needs to be applied as part of publication of that CD as a public review document.
|
'* Line 89: Incorrect Link:
http://docs.oasis-open.org/soa-eerp/eerp-rating/200903/eerp-rating.xsd
Current Correct Link:
*http://docs.oasis-open.org/soa-eerp/rt/v1.0/EERP-Rating-cd03.xsd*
|
|
Sub-task
|
SOAEERP-7
PR08-T2 SOA-EERP-bQoS-Spec-cd03.pdf
|
SOAEERP-18
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 04:04 AM
|
15/Sep/10 09:20 PM
|
|
Requires delivery and approval of CD04. Needs to be applied as part of publication of that CD as a public review document.
|
'* Line 94: Incorrect url:
http://docs.oasis-open.org/soa-eerp/eerp-bqos/200903/eerp-bqos.xsd
Current Correct Link:
*http://docs.oasis-open.org/soa-eerp/bqos/v1.0/EERP-bQoS-cd03.xsd*
|
|
Sub-task
|
SOAEERP-7
PR08-T1 WhitePaper-cd03 Section: *Conceptual Framework and Message Flow*
|
SOAEERP-17
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 04:01 AM
|
04/Aug/10 09:38 PM
|
|
WD09 of Whitepaper, http://www.oasis-open.org/committees/download.php/38426/EERP-Model-UseCase-WhitePaper-wd09-diff-cd03-withLineNumber.pdf , Line 233-227 has the following:
223 Note that this conceptual framework is just one way of implementing the EERP
224 technology. There are alternate ways to implement EERP without the EERP Portal. For
225 example, one could use the ebXML Registry/Repository or similar means to exchange
226 business quality of services information, and begin negotiations for establishing Business
227 Service Level Agreements (bSLAs).
|
'* Note: It appears that an EERP Portal is required. Is this so? If
so, please explain why in this section. This could be more than
some smaller service providers are willing or able to afford, and
requiring third party facilities could be problematic--though I am
personally requiring a similar third party facility in a Network
Centric Pattern (NCP) in the Network Centric Operations Industry
Consortium (NCOIC) All Hazards Alert and Warning Capabilities
(AHAW) NCP in the form of a SOA Registry-Repository for Service
Providers and Consumers to find each other, share Service
Descriptions and acquire the contact information necessary to
begin negotiations for establishing Service Level Agreements (SLAs).
|
WD09 of Whitepaper, http://www.oasis-open.org/committees/download.php/38426/EERP-Model-UseCase-WhitePaper-wd09-diff-cd03-withLineNumber.pdf , Line 233-227 has the following:
223 Note that this conceptual framework is just one way of implementing the EERP
224 technology. There are alternate ways to implement EERP without the EERP Portal. For
225 example, one could use the ebXML Registry/Repository or similar means to exchange
226 business quality of services information, and begin negotiations for establishing Business
227 Service Level Agreements (bSLAs).
|
Sub-task
|
SOAEERP-7
PR08-E8 bQoS-Spec-cd03.pdf, Rating-Specification.pdf, BSLA-spec-cd03.pdf
|
SOAEERP-16
|
Szu Chang
|
Paul Yang
|
Critical
|
Closed
|
Fixed
|
13/May/10 03:56 AM
|
15/Sep/10 08:55 PM
|
|
Changed BQoS schema for extension element from <bqos:Extension> to <bqos:BQoSExtension>.
Change the bQoS spec @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/39307/SOA-EERP-bQoS-Spec-cd04.pdf to the following:
291 /bqos:BQoS/bqos:BQoSExtension
292 BQoSExtension element is an optional element that keeps different (extensible) elements to be
293 specified in the future.
294 /bqos:BQoS/bqos:BQoSExtension/{any}
295 This is an extensibility mechanism to allow different (extensible) elements to be specified in the
296 future. Unrecognized elements MAY cause a fault or be silently ignored.
Changed bRating schema for extension element from <rt:Extension> to <rt:BRatingExtension>.
Change the bRating spec @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/39321/SOA-EERP-bRating-Spec-cd04.pdf to the following:
279 /rt:BRating/rt:BRatingExtension
280 BRatingExtension element is an optional element that keeps different (extensible) elements to be
281 specified in the future.
282 /rt:BRating/rt:BRatingExtension/{any}
283 This is an extensibility mechanism to allow different (extensible) elements to be specified in the
284 future. Unrecognized elements MAY cause a fault or be silently ignored. This can be one or more
285 elements of /rt:BRaing/rt:BRatingExtension/Performance/QualityAssertionEvaluation for third
286 party Service Rating Entities to provide their evaluation for how well the provider fulfill the Quality
287 Assertion(s) of this service.
Changed bSLA schema for extension element from <sla:Extension> to <sla:BSLAExtension>.
Change the bSLA spec @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/39310/SOA-EERP-bSLA-Spec-cd04.pdf to the following:
320 /sla:BSLA/sla:BSLAExtension
SOA-EERP-bSLA-Spec-cd04 12 September 2010
Copyright © OASIS® 2010. All Rights Reserved. Page 11 of 41
BSLAExtension element is an optional element that keeps different (extensible) 321 elements to be
322 specified in the future.
323 /sla:BSLA/sla:BSLAExtension/{any}
324 This is an extensibility mechanism to allow different (extensible) elements to be specified in the
325 future. Unrecognized elements MAY cause a fault or be silently ignored.
|
'* 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 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.
|
Sub-task
|
SOAEERP-7
PR08-E7 SOA-EERP-BSLA-spec-cd03.pdf
|
SOAEERP-15
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 03:46 AM
|
04/Aug/10 09:29 PM
|
|
Editorial changes applied.
|
'* Lines 10, 11: grammatical error: "...to select _*an*_ optimal
end-to-end solution."
* Lines 134, 135: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 149, 150: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 156, 157: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 160, 161: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 200, 201: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 216, 217: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Line 220: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Lines 262, 263: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 265, 267, 269, 271, 273, 275: Suggestion: "_*Describes*_
available operations..."
* Lines 281, 282: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Line 285: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Lines 320, 321: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 328, 326: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Line 332: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Lines 352, 353: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 360, 361: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 387, 388: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 394, 395: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 401, 402: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 408, 409: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Line 412 is formatted in a different typeface/font from the style
used throughout the rest of the specification for that kind of
body text and should be changed to match the overall style.
* Note the use of a different typeface for the name of elements
immediately after a Numbered Section Title in the following
example does not sufficiently emphasize the name and causes visual
dissonance, and some text passages continue using that different
typeface so, IF this is an artifact of the OASIS specification
template it would be a good idea to point it out, or else use
italic or bold for emphasis because a different typeface that is
not significantly different just looks like an unintentional error.
* Lines 502, 503: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 583, 584: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 599, 600: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 628, 629: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 635, 636: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 776-778 are formatted in a different typeface/font from the
style used throughout the rest of the specification for that kind
of body text and should be changed to match the overall style.
* Line 806-808: grammatical errors: "...implementation silently
_*ignores*_ unrecognized attributes where any attribute is
allowed, or silently _*ignores*_ unrecognized elements where any
element is allowed, should be considered _*an*_ interoperable
implementation."
|
Fixed all those minor editorial problems on WD09 of the bSLA spec, see http://www.oasis-open.org/committees/download.php/38432/SOA-EERP-bSLA-spec-wd09-diff-cd03.pdf
The issue can be closed.
|
Sub-task
|
SOAEERP-7
PR08-E6 SOA-EERP-Rating-Specification.pdf
|
SOAEERP-14
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 03:39 AM
|
04/Aug/10 09:30 PM
|
|
Editorial changes applied.
|
'* Line 3: Suggestion "... information exchange on business
*credibility *reliability and reputation..."
* Line 8: Suggestiion "The *credibility*, reliability and reputation..."
* Line 85: Suggestion: "_*The XML vocabulary for Business Rating is
defined in the XML Schema for this specification with several
specific rating measurement indicators.*_"
* Lines 111-113 are formatted in a different typeface/font from the
style used throughout the rest of the specification for that kind
of body text and should be changed to match the overall style.
* Lines 111-113: grammatical error (111, 112) and suggestion (112):
"Performance:QualityAssestionEvaluation that will _*provide*_ a
mechanism for Service Rating Entities to _*render*_ their
evaluation for how well the Service Provider _*fulfills*_ the
Quality Assertion(s) of its service."
* Line 131: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Line 137, 138: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Lines 145, 146: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Line 149: grammatical error: "... Unrecognized elements MAY cause
a fault or be silently _*ignored*_."
* Line 157: remove white space in element name: An aggregated
number, in _*<rt:RatingNumeric>*_ element."
* Line 187: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Lines 202, 203: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 212, 213: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 218, 219: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 226-228 re formatted in a different typeface/font from the
style used throughout the rest of the specification for that kind
of body text and should be changed to match the overall style.
* Lines 227, 228: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 234-235: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Line 284: Suggestion: "_*Unlike *_the Rating element..."
* Lines 320, 321: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 337, 338: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 341, 342: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 351, 352: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 361, 362: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 369, 370: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 376, 377: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 383, 384: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 390, 391: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 393, 394: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_.
* Lines 453, 454 are formatted in a different typeface/font from the
style used throughout the rest of the specification for that kind
of body text and should be changed to match the overall style.
* Lines 458-460 are formatted in a different typeface/font from the
style used throughout the rest of the specification for that kind
of body text and should be changed to match the overall style.
* Lines 579-582 are formatted in a different typeface/font from the
style used throughout the rest of the specification for that kind
of body text and should be changed to match the overall style.
* Line 609-611: grammatical errors, suggestion: "...implementation
silently _*ignores*_ unrecognized attributes where any attribute
is allowed, or silently _*ignores *_unrecognized elements where
any element is allowed, should be considered _*an*_ interoperable
implementation."
|
Fixed all those minor editorial problems in WD09 of bRating spec, http://www.oasis-open.org/committees/download.php/38429/SOA-EERP-bRating-Spec-wd09-diff-cd03.pdf:
- line 93-93, editing error, "the is defined", please remove "the" to change
Line 91-92
- fix "Service Provider fulfill", either Providers fulfill or "provider fulfills"
Line 119
- Changed all "elements/parameters" to "elements"
No "elements/parameters" found any more.
- /rt:BRaing/Performance/QualityAssestionEvaluation, "Assestion" is not word.
Line 118, 157
- 5.1 Service Rating with an Engineering Service change to 5.1Service Rating for an Engineering Service
Line 461
- changed Style problems - text, t char in some places, Normal in others, should be "Body Text" or "Text Body". Violates
template.
[ Show » ] Szu Chang added a comment - 23/Jun/10 07:01 PM Fixed in WD09 of bRating spec, http://www.oasis-open.org/committees/download.php/38429/SOA-EERP-bRating-Spec-wd09-diff-cd03.pdf: - line 93-93, editing error, "the is defined", please remove "the" to change Line 91-92 - fix "Service Provider fulfill", either Providers fulfill or "provider fulfills" Line 119 - Changed all "elements/parameters" to "elements" No "elements/parameters" found any more. - /rt:BRaing/Performance/QualityAssestionEvaluation, "Assestion" is not word. Line 118, 157 - 5.1 Service Rating with an Engineering Service change to 5.1Service Rating for an Engineering Service Line 461 - changed Style problems - text, t char in some places, Normal in others, should be "Body Text" or "Text Body". Violates template.
|
Sub-task
|
SOAEERP-7
PR08-E5 SOA-EERP-bQoS-Spec-cd03.pdf
|
SOAEERP-13
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 03:37 AM
|
04/Aug/10 09:30 PM
|
|
Editorial changes applied.
|
'* Line 6: grammatical error: "...improve business results. It models
the business process and the range of potential services, then
_*guides*_..."
* Line 10: grammatical error: "..._*an*_ optimal end-to-end solution."
* Lines 137, 138: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 144, 145: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 148, 149: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Line 188: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Line 275: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Line 327: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Lines 337, 338: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Line 340: grammatical error: "... This is an extensibility
mechanism to allow different (extensible) _*properties*_..."
* Lines 451, 452 and 453 are formatted in a different typeface/font
from the style used throughout the rest of specification for that
kind of body text and should be changed to match the overall style.
* Lines 465-467: grammatical errors: "... implementation silently
_*ignores*_ unrecognized attributes where any attribute is
allowed, or silently _*ignores*_ unrecognized elements where any
element is allowed, _*it*_ should be considered as interoperable
implementation."
|
Fixed all those minor editorial problems on WD09 of bQoS spec @ http://www.oasis-open.org/committees/download.php/38435/SOA-EERP-bQoS-Specwd09-diff-cd03.pdf
bullet #2: Line has deleted and no onger apply.
Line 13-14
13 EERP applies the well-known technique for service discovery, composition, simulation, and optimization
14 techniques in a novel way to improve business results.
The issue can be closed.
|
Sub-task
|
SOAEERP-7
PR08-E4 Section: WhitePaper-cd03 Section:*A Guided Tour through the XML Vocabulary Specifications*
|
SOAEERP-12
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 03:31 AM
|
04/Aug/10 09:25 PM
|
|
All changes addressed as appropriate.
|
'* Suggestion: in SubSection: *The Three Specifications:* in third
paragraph: "EERP Business Rating of Services Specification is an
XML vocabulary for information exchange on business
_*credibility*_, reliability and reputation of the service
providers. The _*credibility*_, reliability and reputation..."
* Suggestion: in SubSection: *The Three Specifications:* in
paragraph four "...and to select _*an*_ optimal end-to-end solution."
* Suggestion: in SubSection: *The Three Specifications:* in
paragraph five "...EERP Business Service Level Agreement for
*(BSLA)*" should reflect the resolution of the *General Comment*
above. Also the words "and evaluate" are in a different font for
no apparent reason, so should be changed to match the style of the
rest of the paragraph.
* Suggestion: in SubSection: *The Three Specifications:* in
paragraph six: *BSLA* occurs again, please follow resolution of
*General Comment *above.
* Suggestion: in SubSection: *EERP Business Quality of Service
(bQoS) Specification and Schema:* BQoS occurs several times and
should be consistent with resolution of *General Comment *above.
* Page 15 in first paragraph of Section: *EERP Business Service
Level Agreement Specification:* 2nd line: "... service provider
for a give service." should be "...service provider for a
_*given*_ service."
|
|
Sub-task
|
SOAEERP-7
PR08-E3 WhitePaper-cd03 Section: *Conceptual Framework and Message Flow*
|
SOAEERP-11
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 03:28 AM
|
04/Aug/10 09:24 PM
|
|
All problems on figures number and its captions in Whitepaper have been fixed on WD09, see http://www.oasis-open.org/committees/download.php/38426/EERP-Model-UseCase-WhitePaper-wd09-diff-cd03-withLineNumber.pdf
Line 234, 257, 261, 325, etc.
|
'* First and second sentences in Paragraph three of SubSection:
"Service providers *offer* business services. Each service
provider may *offer* the same service but with different bQoS and
Ratings." "provider(s) provide" is just a bit clumsy--stylistic
consideration only.
* /Description/ column entries for numbers 5 through 12 of the
Tabular presentation of messages in SubSection: *Message Exchange
Example:* are in a larger text size than the rest of the tabular
material.
* /Description/ for number 8 in tabular presentation of messages in
SubSection: Message Exchange Example needs correction : ...*SLA*
Request message...
* /Description/ for number 11 in tabular presentation of messages in
SubSection: *Message Exchange Example*: doesn't make sense to me:
"Service Requester sends SLA Request message to the Service
Providers to obtain the commitments from the Service Providers
_*f**or those no SLA service in the set*_".
* Suggestion: in last paragraph on page 10 SubSection: Message
Exchange Example: "We conclude this section with a _*sequence*_
diagram."
|
All problems on figures number and its captions in Whitepaper have been fixed on WD09, see http://www.oasis-open.org/committees/download.php/38426/EERP-Model-UseCase-WhitePaper-wd09-diff-cd03-withLineNumber.pdf
Line 234, 257, 261, 325, etc.
The issue can be closed.
|
Sub-task
|
SOAEERP-7
PR08-E2 WhitePaper-cd03 Section: *EERP Technology*
|
SOAEERP-10
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 03:17 AM
|
04/Aug/10 09:17 PM
|
|
Szu Chang has applied all of these minor editorial fixes.
|
'* I would like to commend you on the explanation given in
SubSection: *Enablers for Optimization:*
* Specifically, I am very pleased that "The focus of the SOA-EERP
Technical Committee is on enablers for optimization and process
improvement rather than on the complete EERP environment." This
was an unspoken concern of mine early on, and it puts the entire
complement of specifications into a sound perspective. (Note: I
didn't intend to start with agreement and commendation. I must be
slipping!")
* In the second paragraph of SubSection: *Enablers for Optimization:
*the parenthetical phrase "(how to represent cost, time, and
cost)," is clumsy. Perhaps "(how to represent cost, time, and
intended result)," might be better. (Note: the term we use in the
SOA-RAF for intended "result" would be intended "Real World Effect.")
* Suggestion for next to last paragraph of SubSection: *Status of
Standards Process:* "These XML vocabulary specifications address
the exchange of information that models the business
characteristics of a service, permits assertions or queries
related to the credibility of the service and its provider, and
the establishment of agreements about the _*use of*_ business service.
|
|
Sub-task
|
SOAEERP-7
PR08-E1 General Comment (editorial)
|
SOAEERP-9
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
13/May/10 03:10 AM
|
04/Aug/10 09:15 PM
|
|
Fixed in wd09 for four documents.
|
General Comment:* If any of these specifications will start their
abbreviations with a lower case "b" as is done in bQoS, then I think
they should all start their abbreviations with a lower case "b" as in
bRating and bSLA for the sake of consistency, or else the lower case "b"
should be dropped as in QoS, Rating, SLA.
|
To change all to bQOS, bSLA, and bRating uniformly per 06/02/2010 TC meeting
Changed all 4 documents on WD09, they are:
http://www.oasis-open.org/committees/download.php/38435/SOA-EERP-bQoS-Specwd09-diff-cd03.pdf
http://www.oasis-open.org/committees/download.php/38432/SOA-EERP-bSLA-spec-wd09-diff-cd03.pdf
http://www.oasis-open.org/committees/download.php/38429/SOA-EERP-bRating-Spec-wd09-diff-cd03.pdf
http://www.oasis-open.org/committees/download.php/38426/EERP-Model-UseCase-WhitePaper-wd09-diff-cd03-withLineNumber.pdf
This issue can be closed.
|
Improvement
|
PR06 - from Hu Caiyong: What is the service in the SOA-EERP?
|
SOAEERP-8
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
05/May/10 01:46 AM
|
17/Sep/10 06:27 AM
|
|
Andy Lee Replied and Yulin has updated WD10 to address three outstanding issues together:
http://tools.oasis-open.org/issues/browse/SOAEERP-8
http://tools.oasis-open.org/issues/browse/SOAEERP-22
http://tools.oasis-open.org/issues/browse/SOAEERP-25
The changes are:
bQoS Spec WD10 @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/document.php?document_id=39238, Line 141-142
bRating Spec WD10 @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/document.php?document_id=39239, Line 141-142
bSLA Spec WD10 @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/document.php?document_id=39240, Line 148-149
White paper WD10 @ , http://www.oasis-open.org/apps/org/workgroup/soa-eerp/document.php?document_id=39237, on page 5, Introduction section, second paragraph, added the following text:
In this context, a service is a component capable of performing a task, or a type of capability described using WSDL, while SOA is referred to by W3C (World Wide Web Consortium) as a set of components which can be invoked, and whose interface descriptions can be published and discovered. The applications of these three specifications are any kind of business services, and they are not limited to only Web Services.
The above changes then have incorporated into WD11 for the candidate of CD04. They are:
bQoS spec @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/39374/SOA-EERP-bQoS-Spec-wd11.pdf
138 ... The applications of this specification are any kind of business services, and they are not
139 limited to only Web Services.
bRating spec @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/39379/SOA-EERP-bRating-Spec-wd11.pdf
135 ... The applications of this specification
136 are any kind of business services, and they are not limited to only Web Services.
bSLA Spec @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/39377/SOA-EERP-bSLA-Spec-wd11.pdf
150 ... The applications of this specification are any kind of business
151 services, and they are not limited to only Web Services.
White paper WD11 @ http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/39370/EERP-Model-UseCase-WhitePaper-wd11.pdf, page 5, second paragraph, whole section
|
Hi:
I have reviewed these three specs posted. They are very interesting. I have a high level question: what is the target service for these three specs to apply to? Is this for SOA Web Services only, or can be applied to other kind of services? For example, can these three specs be applied to Software as a Service (SaaS) in the Cloud?
Hu Caiyong
Redflag Chinese 2000 Co. Ltd.
Email: hucaiyong@RedOffice.com
OASIS URL link to the email:
http://lists.oasis-open.org/archives/soa-eerp-comment/201004/msg00004.html
|
In addition to the reply by Andy with the following text:
"Caiyong,
Thanks for your comments.
As stated in the white paper End-to-End Resource Planning (EERP) Model and Use Cases, SOA-EERP Services are performed by people, machines, and hardware/software applications, and represented by SOA services. The application of these three specs are any kind of business services, and they are not limited to only Web Services.
Software as A Service (SaaS) in the Cloud will also need to deal with business quality of service, rating of the service and the business service level agreement. Therefore, these three SOA-EERP specs can be applied to SaaS as well.
Best regards,
Andy Lee,
SOA-EERP TC Co-chair"
It is proposed to add the following text to three specs:
"The applications of this specification are any kind of business services, and they are not limited to only Web Services."
And add the following text to the white paper:
"In this context, a service is a component capable of performing a task, or a type of capability described using WSDL, while SOA is referred to by W3C (World Wide Web Consortium) as a set of components which can be invoked, and whose interface descriptions can be published and discovered. The applications of these three specifications are any kind of business services, and they are not limited to only Web Services."
|
Improvement
|
PR08 - from Rex Brooks: Comments on Public Review Drafts cd03
|
SOAEERP-7
|
William Cox
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
16/Apr/10 05:19 AM
|
29/Sep/10 08:11 PM
|
|
All subissues are closed.
|
Rex Brooks sent following comments on 4/2/2010:
Greetings,
Sorry I found myself overextended, so needed to curtail my participation
in the SOA-EERP TC. However, I applaud the improvements you have made in
these specifications. I am copying the SOA Reference Model TC and the
SOA Reference Architecture SC to keep them apprised of my comments. I
will start with the White Paper, then address bQoS, bSLA and Rating. I
am making my comments based on the pdf versions.
For the SOA RM TC and SOA RM RA SC I am providing the announcement url
that can be used for downloading these documents:
http://www.oasis-open.org/apps/org/workgroup/soa-eerp/email/archives/201002/msg00000.html
I have designated errors and/or suggestions with _*boldface and
underlined text.*_
*
General Comment:* If any of these specifications will start their
abbreviations with a lower case "b" as is done in bQoS, then I think
they should all start their abbreviations with a lower case "b" as in
bRating and bSLA for the sake of consistency, or else the lower case "b"
should be dropped as in QoS, Rating, SLA.
EERP-Model-UseCase-WhitePaper-cd03
Section: *EERP Technology*
* I would like to commend you on the explanation given in
SubSection: *Enablers for Optimization:*
* Specifically, I am very pleased that "The focus of the SOA-EERP
Technical Committee is on enablers for optimization and process
improvement rather than on the complete EERP environment." This
was an unspoken concern of mine early on, and it puts the entire
complement of specifications into a sound perspective. (Note: I
didn't intend to start with agreement and commendation. I must be
slipping!")
* In the second paragraph of SubSection: *Enablers for Optimization:
*the parenthetical phrase "(how to represent cost, time, and
cost)," is clumsy. Perhaps "(how to represent cost, time, and
intended result)," might be better. (Note: the term we use in the
SOA-RAF for intended "result" would be intended "Real World Effect.")
* Suggestion for next to last paragraph of SubSection: *Status of
Standards Process:* "These XML vocabulary specifications address
the exchange of information that models the business
characteristics of a service, permits assertions or queries
related to the credibility of the service and its provider, and
the establishment of agreements about the _*use of*_ business service.
Section: *Conceptual Framework and Message Flow*
* First and second sentences in Paragraph three of SubSection:
"Service providers *offer* business services. Each service
provider may *offer* the same service but with different bQoS and
Ratings." "provider(s) provide" is just a bit clumsy--stylistic
consideration only.
* Note: It appears that an EERP Portal is required. Is this so? If
so, please explain why in this section. This could be more than
some smaller service providers are willing or able to afford, and
requiring third party facilities could be problematic--though I am
personally requiring a similar third party facility in a Network
Centric Pattern (NCP) in the Network Centric Operations Industry
Consortium (NCOIC) All Hazards Alert and Warning Capabilities
(AHAW) NCP in the form of a SOA Registry-Repository for Service
Providers and Consumers to find each other, share Service
Descriptions and acquire the contact information necessary to
begin negotiations for establishing Service Level Agreements (SLAs).
* /Description/ column entries for numbers 5 through 12 of the
Tabular presentation of messages in SubSection: *Message Exchange
Example:* are in a larger text size than the rest of the tabular
material.
* /Description/ for number 8 in tabular presentation of messages in
SubSection: Message Exchange Example needs correction : ...*SLA*
Request message...
* /Description/ for number 11 in tabular presentation of messages in
SubSection: *Message Exchange Example*: doesn't make sense to me:
"Service Requester sends SLA Request message to the Service
Providers to obtain the commitments from the Service Providers
_*f**or those no SLA service in the set*_".
* Suggestion: in last paragraph on page 10 SubSection: Message
Exchange Example: "We conclude this section with a _*sequence*_
diagram."
Section: *A Guided Tour through the XML Vocabulary Specifications*
* Suggestion: in SubSection: *The Three Specifications:* in third
paragraph: "EERP Business Rating of Services Specification is an
XML vocabulary for information exchange on business
_*credibility*_, reliability and reputation of the service
providers. The _*credibility*_, reliability and reputation..."
* Suggestion: in SubSection: *The Three Specifications:* in
paragraph four "...and to select _*an*_ optimal end-to-end solution."
* Suggestion: in SubSection: *The Three Specifications:* in
paragraph five "...EERP Business Service Level Agreement for
*(BSLA)*" should reflect the resolution of the *General Comment*
above. Also the words "and evaluate" are in a different font for
no apparent reason, so should be changed to match the style of the
rest of the paragraph.
* Suggestion: in SubSection: *The Three Specifications:* in
paragraph six: *BSLA* occurs again, please follow resolution of
*General Comment *above.
* Suggestion: in SubSection: *EERP Business Quality of Service
(bQoS) Specification and Schema:* BQoS occurs several times and
should be consistent with resolution of *General Comment *above.
* Page 15 in first paragraph of Section: *EERP Business Service
Level Agreement Specification:* 2nd line: "... service provider
for a give service." should be "...service provider for a
_*given*_ service."
Note: I did not attempt to validate or otherwise test the XML Schemas or
Examples for the White Paper or the Specifications. I will validate the
schemas separately and only report if I discover problems. I won't test
the examples.
SOA-EERP-bQoS-Spec-cd03.pdf
* Line 6: grammatical error: "...improve business results. It models
the business process and the range of potential services, then
_*guides*_..."
* Line 10: grammatical error: "..._*an*_ optimal end-to-end solution."
* Line 94: Incorrect url:
http://docs.oasis-open.org/soa-eerp/eerp-bqos/200903/eerp-bqos.xsd
Current Correct Link:
*http://docs.oasis-open.org/soa-eerp/bqos/v1.0/EERP-bQoS-cd03.xsd*
* Lines 137, 138: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 144, 145: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 148, 149: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Line 188: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Line 275: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Line 327: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Lines 337, 338: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Line 340: grammatical error: "... This is an extensibility
mechanism to allow different (extensible) _*properties*_..."
* Lines 451, 452 and 453 are formatted in a different typeface/font
from the style used throughout the rest of specification for that
kind of body text and should be changed to match the overall style.
* Lines 465-467: grammatical errors: "... implementation silently
_*ignores*_ unrecognized attributes where any attribute is
allowed, or silently _*ignores*_ unrecognized elements where any
element is allowed, _*it*_ should be considered as interoperable
implementation."
* 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."
SOA-EERP-Rating-Specification.pdf
* Line 3: Suggestion "... information exchange on business
*credibility *reliability and reputation..."
* Line 8: Suggestiion "The *credibility*, reliability and reputation..."
* Line 85: Suggestion: "_*The XML vocabulary for Business Rating is
defined in the XML Schema for this specification with several
specific rating measurement indicators.*_"
* Line 89: Incorrect Link:
http://docs.oasis-open.org/soa-eerp/eerp-rating/200903/eerp-rating.xsd
Current Correct Link:
*http://docs.oasis-open.org/soa-eerp/rt/v1.0/EERP-Rating-cd03.xsd*
* Lines 111-113 are formatted in a different typeface/font from the
style used throughout the rest of the specification for that kind
of body text and should be changed to match the overall style.
* Lines 111-113: grammatical error (111, 112) and suggestion (112):
"Performance:QualityAssestionEvaluation that will _*provide*_ a
mechanism for Service Rating Entities to _*render*_ their
evaluation for how well the Service Provider _*fulfills*_ the
Quality Assertion(s) of its service."
* Line 131: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Line 137, 138: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Lines 145, 146: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Line 149: grammatical error: "... Unrecognized elements MAY cause
a fault or be silently _*ignored*_."
* Line 157: remove white space in element name: An aggregated
number, in _*<rt:RatingNumeric>*_ element."
* Line 187: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Lines 202, 203: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 212, 213: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 218, 219: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 226-228 re formatted in a different typeface/font from the
style used throughout the rest of the specification for that kind
of body text and should be changed to match the overall style.
* Lines 227, 228: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 234-235: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Line 284: Suggestion: "_*Unlike *_the Rating element..."
* Lines 320, 321: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 337, 338: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 341, 342: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 351, 352: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 361, 362: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 369, 370: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 376, 377: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 383, 384: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 390, 391: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 393, 394: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_.
* Lines 453, 454 are formatted in a different typeface/font from the
style used throughout the rest of the specification for that kind
of body text and should be changed to match the overall style.
* Lines 458-460 are formatted in a different typeface/font from the
style used throughout the rest of the specification for that kind
of body text and should be changed to match the overall style.
* Lines 579-582 are formatted in a different typeface/font from the
style used throughout the rest of the specification for that kind
of body text and should be changed to match the overall style.
* Line 609-611: grammatical errors, suggestion: "...implementation
silently _*ignores*_ unrecognized attributes where any attribute
is allowed, or silently _*ignores *_unrecognized elements where
any element is allowed, should be considered _*an*_ interoperable
implementation."
* 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."
SOA-EERP-BSLA-spec-cd03.pdf
* Lines 10, 11: grammatical error: "...to select _*an*_ optimal
end-to-end solution."
* Line 106: Incorrect url:
http://docs.oasis-open.org/soa-eerp/eerp-sla/200903/eerp-sla.xsd
Current Correct Link:*
http://docs.oasis-open.org/soa-eerp/sla/v1.0/EERP-SLA-cd03.xsd*
* Line 110: Suggestion: "... Technical _*aspects*_ such as service
availability, accessibility, ..."
* Lines 134, 135: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 149, 150: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 156, 157: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 160, 161: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 200, 201: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 216, 217: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Line 220: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Lines 262, 263: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 265, 267, 269, 271, 273, 275: Suggestion: "_*Describes*_
available operations..."
* Lines 281, 282: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Line 285: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Lines 320, 321: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 328, 326: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Line 332: grammatical error: "... Unrecognized attributes MAY
cause a fault or be silently _*ignored*_."
* Lines 352, 353: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 360, 361: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 387, 388: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 394, 395: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 401, 402: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 408, 409: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Line 412 is formatted in a different typeface/font from the style
used throughout the rest of the specification for that kind of
body text and should be changed to match the overall style.
* Note the use of a different typeface for the name of elements
immediately after a Numbered Section Title in the following
example does not sufficiently emphasize the name and causes visual
dissonance, and some text passages continue using that different
typeface so, IF this is an artifact of the OASIS specification
template it would be a good idea to point it out, or else use
italic or bold for emphasis because a different typeface that is
not significantly different just looks like an unintentional error.
5.1.1.2 CommittedTime
The Committed Time, Committed Time element of Service Level Objective
for Obligation in SLA Obligations in EERP-SLA, is the committed time
period in SLA, including Duration, Latency and Committed Completion Time.
* Lines 502, 503: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 583, 584: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 599, 600: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 628, 629: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 635, 636: grammatical error: "... Unrecognized attributes
MAY cause a fault or be silently _*ignored*_."
* Lines 776-778 are formatted in a different typeface/font from the
style used throughout the rest of the specification for that kind
of body text and should be changed to match the overall style.
* Line 806-808: grammatical errors: "...implementation silently
_*ignores*_ unrecognized attributes where any attribute is
allowed, or silently _*ignores*_ unrecognized elements where any
element is allowed, should be considered _*an*_ interoperable
implementation."
Good work. This is a substantial improvement.
Cheers,
Rex
Email: rexb@starbourne.com
|
|
Improvement
|
PR07 - from Bill Cox: Comments on Public Review of SOA-EERP specifications
|
SOAEERP-6
|
William Cox
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
16/Apr/10 05:11 AM
|
17/Sep/10 06:34 AM
|
|
All subissues are closed.
|
Bill Cox sent following comments on 4/3/2010:
1. The terminology appears to be inconsiteent with that in the SOA Reference Model. Terminology alignment with that specification. This applies to the White Paper, and the explanatory sections of all three specification. In particular, at least the use of "Service" should be made consistent in all SOA-EERP specifications.
2. Editorial: Many sections start on a left hand (verso) page. They should start on a right hand (recto) page.
3. All issues identified as "Deferred" in the TC issues list dated 2009-10-24 Revision 18 should be opened and considered.
4. The TC should consider whether the details of how services and service providers are identified is consistent with good parctices in defingin information exchanges. In other words, these specifications may need to change due to design considerations for the protocol, which is not being reviewed at this time. A review with a future version of these specifications and the protocol should undergo a unified public review in the future.
5. bqOs lines 5ff: a service is not defined in this specification, yet "service discovery" is applied. All uses of service must be examined for consistency with the "service" in Service Oriented Architecture. "Business Service" is a new definition in these specs and should be carefully and clearly defined. This comment applies to all of the specifications -- service is used frequently but not defined and without reference to SOA-RM.
6. The tiles of the specs and the TC strongly suggest that the Soa meaning is implied, but is never stated.
7. Likewise, "Business Service Level Agreement" suggests a relatoinship to SOA-and SOA RM, but the relationship is never stated.
8. A non-normative section should be included in each specification showing additional samples, and demonstrating that empty or nearly empty artifacts do not conform.
9. The White paper does not carefully define a model or architecture for interaction; those aspects of EERP should be spelled out in the forthcoming protocol specification. Some may be better in these specifications, e.g., could it be stated that only a rating service returns a rating list? and only a business service (still undefined) returns credentials?
10. The use of "third party" (e.g., in Rating lines 100) is problematic. Does the specification assert that only "third parties", which is taken to mean "parties unaffiliated with either the requester or the target of the rating request" will respond? The conformance clauses on this issue are extremely weak. This is another area where the overall architecture, in a normative form rather than a white paper, is essential to understanding.
11. Again in Rating, line 624 (and similar locations in the other specs): OASIS specifies that the normative schema is that in the identified separate file. This should be noted in all of the schemas in the specifications. In (e.g.) bQoS, Appendix B "Non-Normative Text" says "none" but is followed by non-normative Appendix C which is not identified as non-normative.
12. In Rating, not enough is done to connect "Credentials" to the common uses of the term, including in security and business. This is essential.
13. In BSLA Non-Normative text is Appendix C, preceded by the SML Schema. This should be identified per OASIS rules as non-normative and that the separate XSD file is normative.
14. BSLA lines 1-12. This is not sufficient to connect the notion of a BUSINESS Service Level Agreement to an SLA as understood in the software/IT world. An explanation connecting, contrasting, and comparing the notoins should be included. There is some defition in 2.3 (line 108-110) which partially satisfies this. In conjunction with comment 15 this needs to be more clear and more prominently placed at the beginning of the document in Section 1.
15. All three specifications use common words (e.g. Service, SLA, Quality of Service, Rating, Credentials) but do not define them or reference the relevant definitions. All the specifications should carefully compare and conrast, and where a specific technical meaning or meaning may be understood, indicate whether that meaning is intended. Otherwise the documents are hard to comprehend. The missing comparison and contast beteween "SLA" and "BSLA" is one case in point (see item 14). The connections all need to be explicit, not implicit or suggested (but never confirmed). The documents read as if there were a detailed architectural and interaction model that is understood by the authors but never explained to the readers. This is a barrier to implementation, understanding, and conformance.
16. BSLA table 1, udt - why does this referenc both UBL and CEFAACT when it's a urn to CEFACT?
17. the reference to services and other things are all URIs. How can an implementation determine which kind of service or entity is at the URI used? This is in all three specifications.
bill cox
Email: wtcox@CoxSoftwareArchitects.com
|
Same as SOAEERP-7, close it when all subissues are closed.
|
Improvement
|
PR05 - from Chunqing Li: What is the SLA in the SOA-EERP?
|
SOAEERP-5
|
William Cox
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
16/Apr/10 05:06 AM
|
04/Aug/10 09:11 PM
|
|
No change to document.
|
Chunqing Li sent following comments on 4/2/2010:
I have reviewed these three specs posted. They are very interesting. I have a question: what is the purpose of SLA in the real business application? Do the technologies like RMI and Corba can do the same thing as SLA?
Chunqing Li
TongTech
Email: cli@tongtech.com
|
|
New Feature
|
PR04 - from Junghee Yun: WSQM TC's comments
|
SOAEERP-4
|
William Cox
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
16/Apr/10 05:00 AM
|
04/Aug/10 09:10 PM
|
|
Collaboration so a future version of their spec and EERP work well together; no action at present. Comment rejected for cd04 mark no fix.
|
Junghee Yun sent following comments on 4/2/2010:
I am a member of the WSQM TC in OASIS.
Our TC members have reviewed SOA-EERP TC's three specifications and a whitepaper. They are very interesting.
Particularly, the Business Quality of Service specification is considerably related to our TC's works. WSQM TC is developing "Web Services Quality Factors (http://www.oasis-open.org/apps/org/workgroup/wsqm/document.php?document_id=35420)."
The WSQF consists of several quality factors, such as Business Value Quality, Service Level Measurement Quality, Interoperability Quality, Business Processing Quality, Manageability Quality and Security Quality. Our TC is going to submit this specification for the OASIS public review in April. The Business Value Quality includes Price as a sub-quality factor and the Service Level Measurement Quality indicates the performance of service. The WSQF can be applied to services in Service-Oriented Architecture.
Our opinion is following:
The Business Quality of Service specification can be aligned with our Web Services Quality Factors, such that the sub-elements of BQoSPrice and BQoSPerformance are changed to Extension elements which can represent any sub-factors about Price and Performance. And the BQoS specification can refer to our definitions and descriptions of quality factors and sub-quality factors. After that, our WSQF specification can include the Price and Performance as the quality factors and two specifications can be aligned well.
Thank you very much.
Sincerely
Junghee Yun
Email: yunjh@nia.or.kr
|
|
Improvement
|
PR03 - from Pine Zhang: What is the service in the SOA-EERP?
|
SOAEERP-3
|
Szu Chang
|
Paul Yang
|
Minor
|
Closed
|
Fixed
|
16/Apr/10 04:56 AM
|
29/Sep/10 08:12 PM
|
|
The PR comments have replied.
The proposed changes will be addressed on issue SOAEERP-32. Closed duplicated.
|
Following is the comments from Pine on 4/2/2010:
I have reviewed these three specs posted. They are very interesting. I have
a question: what is the difference between rating of a service and the
authentication of a service? Furthermore, what type of business is to
provide the rating service?
Pine Zhang.
Sursen
|
"(WTC) include Rating Credentials as a defined term. Replace all uses of "credential(s) with "Rating Credential(s)".
Define the term as follows:
Rating Credentials include but are not limited to licenses, permissions, certifications, awards, associations, degrees, quality descriptions, and affiliations. They describe a specific service or set of services by a particular service provider.*
*Rating Credentials are distinct from security credentials, although the core meaning is related. Rating Credentials suggest the value or quality of a given service offered by a service provider. [FOOTNOTE TO DEFINITION]
|
Improvement
|
PR02 - from Guangbin Hu: What is the implementation strategy...
|
SOAEERP-2
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
16/Apr/10 04:51 AM
|
04/Aug/10 09:05 PM
|
|
|
Following is Guangbin Hu comments on 4/2/2010:
I have reviewed these three specs posted. They are very interesting. I have a question: what is the implementation strategy for the SLA in the SOA-EERP?
胡广斌
中企开源
Email: huguangbin@ceopen.cn
____________________________________________________________________________________
Following is Bill's response on 4/2/2010:
Do you have additional specific comments on the specs? I'm not certain what you mean by implementation strategy - BSLA is an information artifact that would be exchanged. The white paper describes the use.
Each of the data artifact types, BQoS, BSLA and Rating will be used in message exchanges.
Thanks for your email!
bill cox
____________________________________________________________________________________
|
|
Improvement
|
PR01 - from Eclogue Chang: broken link on EERP-SLA.xsd
|
SOAEERP-1
|
Szu Chang
|
Paul Yang
|
Major
|
Closed
|
Fixed
|
16/Apr/10 04:22 AM
|
15/Sep/10 09:24 PM
|
|
Requires delivery and approval of CD04. Needs to be applied as part of publication of that CD as a public review document.
|
Following is the comments from Eclogue Chang on 3/18/2010:
The SLA namespace page at http://docs.oasis-open.org/ns/soa-eerp/sla/200903爃as a broken link on EERP-SLA.xsd. It points to http://docs.oasis-open.org/soa-eerp/eerp-sla/200903/eerp-sla.xsd which will return 404 -- Page燦ot Found error.
Where is the SLA schema located?
Eclogue Chang
email: e1bridge@yahoo.com
————————————————————————————————————————————————
Szu's reply to this Eclogue Chang on 3/20/2010:
Eclogue,
Thanks for your comments. EERP-SLA.xsd can be found at
http://docs.oasis-open.org/soa-eerp/sla/v1.0/EERP-SLA-cd03.xsd.
There is a typo on the namespace page
http://docs.oasis-open.org/ns/soa-eerp/sla/200903, and will be fixed soon.
___________________________________________________________________________________
Eclogue Chang's response on 3/29/2010:
Thanks for the reply on the SLA Schema location. Howver, when I tried to open the the schema at http://docs.oasis-open.org/soa-eerp/sla/v1.0/EERP-SLA-cd03.xsd聽with my XML editing tool to veiw the schema, I got the following error:
"SchemView is unable to load following schema(s):
http://docs.oasis-open.org/soa-eerp/eerp-bqos/200903/eerp-bqos.xsd"
Looks like it is a problem on the SLA Schema.
|
|
|