http://docs.oasis-open.org/soa-eerp/issues/
SOA-EERP TC Issues List
Date: 2009/7/7
Revision: 11
spec
schema
example
all
interop
New
Active
Pending
Review
Deferred
Closed
Dropped
Should a complete bQoS example be included on the bQoS spec?
This issue was raised during the TC meeting on 4/15/2009. There are small
examples in sections for EERPPrice, EERPPerformance and EERPQuality, but
does not have an example for whole BQoS in the WD01. The whole bQoS example
can be found on the EERP Use Case and Example document.
EERP-bQoS
spec
editorial
Szu Chang
Szu Chang
spec example
New version of bQoS, Working draft 02, has been uploaded at http://www.oasis-open.org/committees/download.php/32306/BusinessQualityOfService-v1.0-spec-wd02.doc and it has the whole example for bQoS on new session 6.
Status changed to Closed on April 29th TC call.
Other quality indicators for bQoS
This issue was raised during the TC meeting on 4/15/2009 by James Zhang.
The current bQoS only has elements Price, time/Performance and name-value
pairs for Quality. Should other web services or software type of QoS
indicators be included for the bQoS spec, such as security, reliability,
etc.?
EERP-bQoS
spec
design
Szu Chang
Szu Chang
N/A
This issue is addressed on WD03 at
http://www.oasis-open.org/committees/download.php/32450/BusinessQualityOfService-v1.0-spec-wd03.doc
Line 146 to Line 152.
Propose to close the issue with above spec changes.
Status changed to "CLOSE pending verification of changes" on May 13th TC call.
Status changed to "CLOSED" on May 27th TC call.
How to reference/use the Unit and Currency code
This issue was raised during the TC meeting on 4/15/2009 by Bill Cox and
Carl. In Use case and example, page 6, embedded - unitCode=each, for
example.
Bill: UnitCode from UBL. Currency code from there as well. Same as (or
derived from) UN-CEFACT. Concerned about pulling in too much of UBL for
just currency code and units. Also as much as the reference is interesting,
easier to resolve to the value "ea" for readability. End resolution is
easier to understand. Agree that supplying a URN is a valuable definition,
but simpler when one reads it to see the end result which would be "ea".
Carl: Same thing, but one is simpler and easier to read than the other.
Need to agree on what put in.
EERP-bQoS
spec
design
Szu Chang
Szu Chang
N/A
In bQoS schema, there are many cases use UBL CommonBasicComponents (CBC)
element or UnqualifiedDataTypesSchemaModule (UDT) now.
This include:
<xsd:element name="Amount" type="cbc:AmountType">
<xsd:element name="Duration" type="cbc:DurationMeasureType">
<xsd:element name="Latency" type="cbc:DurationMeasureType">
<xsd:element name="Quantity" type="cbc:BaseQuantityType">
<xsd:element name="Unit" type="cbc:BaseUnitMeasureType">
<xsd:complexType name="PropertyNameType">
<xsd:complexType name="PropertyValueType">
<xsd:element name="StartTime" type="udt:DateTimeType">
Other two schema files also reference many elements from UBL.
In other words, including UBL is NOT for just currency code and units.
In the feature schema design, more UBL elements will be referenced. This
will leverage the existing components and development on UBL, and reduce
the complexity of our EERP schema.
It is proposed not to change this UBL references.
On May 13th TC call:
Bill: propose to close, open a new item on UBL inclusion in
general.
Per TC meeting notes on 5/13/2009, this issue is closed, and new issue is
open for UBL inclusion in general at #i016
i004
i016
Name Space Names Not Intuitive
This issue was raised during the TC meeting on 4/15/2009 by Bill Cox. In
bQoS schema, it uses namespace like clm66411 and clm54217 which are not
intuitive.
EERP-bQoS
spec
editorial
Szu Chang
Szu Chang
N/A
The name space names, such as clm66411 and clm54217, are come from UBL
2.0's CBC schema:
<xsd:import
namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponent
s-2"
schemaLocation="http://docs.oasis-open.org/ubl/os-UBL-2.0/xsd/common/UBL-Com
monBasicComponents-2.0.xsd"/>
This cannot be changed, unless we drop the CommonBasicComponents schema and
write our own schema for currency code and language code, which should be
addressed on Issue # I003.
Propose to close this issue with no action.
Issue 4 is similar to I003.
On May 13th TC call: Issue I004 will leave it open for now.
Status changed to "CLOSED" on May 27th TC call.
i003
Too many units in bQoS schema
This issue was raised during the TC meeting on 4/15/2009 by Bill Cox. In bQoS schema, it has too many units, perhaps, could use simpler model? Or IETF iCalendar (used in Buildings, Energy)?
EERP-bQoS
spec
design
Szu Chang
Bill Cox
N/A
Units used in bQoS schema include the following:
- Unit for Unit of Measurement in Unit element
- Unit in Time Period, such as Duration and Latency
- Unit in Quantity
All those unit are required to describe the amount, time and quantity to
me.
It is proposed:
1. To assign this issue to Bill Cox for coming up an alternative proposal.
Or
2. Close with no action.
Reassign to Bill Cox.
Still open. Bill will respond before next meeting.
Andy:I have reviewed the examples provided in the bQoS Spec. From those
examples, I think all units in the bQoS schema are useful, and we
should keep all units in the schema.
Hong:I agreed with Andy assessment that all units in bQoS are required
and should not be simplified. Looking into the example in Line 393 and
on:
393 (01) <?xml version="1.0" encoding="UTF-8"?>
394 (02) <bqos:BQoS xmlns:bqos="..." ... >
395 (03) <bqos:BQoSPrice>
396 (04) <bqos:Price>
397 (05) <bqos:Unit unitCode="EA">1000</bqos:Unit>
398 (06) <!-- CNY: Chinese Yuan -->
399 (07) <bqos:Amount currencyID="CNY">120000</bqos:Amount>
400 (08) </bqos:Price>
401 (09) </bqos:BQoSPrice>
402 (10) <bqos:BQoSPerformance>
403 (11) <bqos:Throughput>
404 (12) <!-- delivery: 1 week -->
405 (13) <bqos:Duration unitCode="DAY">7</bqos:Duration>
406 (14) <!-- batch production, generally 1000 sets a batch -->
407 (15) <bqos:Quantity>1000</bqos:Quantity>
408 (16) <bqos:Latency unitCode="DAY">0</bqos:Latency>
409 (17) </bqos:Throughput>
410 (18) </bqos:BQoSPerformance>
411 (19) <bqos:BQoSQualities>
. . .
426 (32) </bqos:BQoSQualities>
427 (33) </bqos:BQoS>
The unitCode on Price, Duration and Latency are all required for
describing Price and Time.
Propose to close this issue with no action.
Agreed by all TC member to to close this issue with no action.
Status changed to "CLOSED" on June 10th TC call.
Further review of bQoS schema
This issue was raised during the TC meeting on 4/29/2009. Need to further
review of bQoS schema. Also, need to ensure that EVERY element is fully
defined in the document. It is essential before public review.
The schema needs to be placed on the Specifications / bqos folder.
EERP-bQoS
schema
design
Szu Chang
Szu Chang
N/A
EERP-bQoS schema has posted on
http://www.oasis-open.org/committees/download.php/32422/EERP-bQoS-wd01.xsd
for review.
Proposed to change to action item and close the issue.
Status changed to Closed on May 13th TC call.
Change Rate to Rating
This issue was raised during the spec review at the TC meeting on
4/29/2009. Carl Mattocks suggested that RATE is not same meaning as
RATING.
All references of "Rate" in the spec and schema should be changed to
"Rating". For example, ListOfRate should be changed to ListOfRating.
EERP-Rating
schema
editorial
Szu Chang
Szu Chang
N/A
Spec Working Draft 02 uploaded at
http://www.oasis-open.org/committees/download.php/32470/BusinessRating-v1.0-
spec-wd02.doc and the XML Schema for Working Draft 02 uploaded at
http://www.oasis-open.org/committees/download.php/32471/EERP-Rating-WD02.xsd
have changed all "Rate" to "Rating". This includes the syntax, description,
examples and xml schema.
This issue can be closed
Status changed to Closed on May 13th TC call.
Some editorial comments on draft Rating spec
This issue was raised during the spec review at the TC meeting on
4/29/2009. Carl Mattocks suggested that may be mitigated by stating STATUS
and intended USE of (draft) document in beginning.
Carl Mattocks also commented that the CONFORMANCE section in the WD01
looks bad, but a CONFORMANCE section must be in the document , certainly before
published outside of TC
EERP-Rating
spec
editorial
Szu Chang
Szu Chang
N/A
Insert the following text to all three spec per Rex Brooks:
"This document is a Work in Progress only and has not been extensively
reviewed. Comment on this document is encouraged. This document is one of
three closely related specifications, SOA-EERP Business Quality of Service
(bQoS), SOA-EERP Rating and SOA-EERP Service Level Agreement which need
to be understood in combination as a set."
Szu Chang proposed to remove the Conformance section for now. The section
can be added before public review.
Working Draft 02, uploaded at
http://www.oasis-open.org/committees/download.php/32470/BusinessRating-v1.0-
spec-wd02.doc, has the following changes:
Insert the proposed text per Rex Brooks on Page 1, Related work and Page 2
status.
The Conformance section has been removed.
This issue can be closed.
On May 13th TC call:
change OK, except conformance section must be
there. Leave open.
Issue 008, Conformance section should not been removed.
Working Draft 03, uploaded at
http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/32571/BusinessRating-v1.0-spec-wd03.pdf, has the following changes:
The Conformance section has been inserted.
This issue can be closed.
Status changed to "CLOSED" on May 27th TC call.
i013
i014
Put a complete example into the Rating spec
This issue was raised during the spec review at the TC meeting on
4/29/2009 by Szu Chang. Like the bQoS spec, a complete example of Rating message
example should be included in the Rating spec.
EERP-Rating
spec
editorial
Szu Chang
Szu Chang
Examples
Spec Working Draft 02 uploaded at
http://www.oasis-open.org/committees/download.php/32470/BusinessRating-v1.0-
spec-wd02.doc has inserted two complete examples from Line 430 to 553.
This issue can be closed.
Status changed to Closed on May 13th TC call.
Relationship between ListOfRating and Credentials Elements
This issue was raised during the spec review at the TC meeting on
4/29/2009.
Carl Mattocks agreed schema elements is an issue and suggested that it may
help differentiate between CREDENTIAL and RATING.
James Zhang noted that: By looking at the rating schema, it appears that
the two elements "rating" and "credential" are related. However a chat
with
Szu indicates that they are not related at all. It seems to be very
confused to put them into one schema if they are not related. A suggestion
is to explicitly mention them that they are not related somewhere in the
spec. Another suggestion is to separate them into two schemas
Carl Mattocks suggested that it would be useful to have individual
examples
and collective example showing credential and rating.
EERP-Rating
schema
design
Szu Chang
Szu Chang
N/A
Update of EERP-Rating schema has posted on
http://www.oasis-open.org/committees/download.php/32471/EERP-Rating-WD02.xsd
for further review on this issue, see
http://lists.oasis-open.org/archives/soa-eerp/200905/msg00032.html
On May 13th TC call:
James: annotation in the schema, or
write something on the spec.
I010 James propose to add some annotation and spec to
indicate they are not related.
Working Draft 03, uploaded at
http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/32571/BusinessRating-v1.0-spec-wd03.pdf, Section 2, line 101 to line 119 has detailed write-up for
the relationship between ListOfRating and Credentials elements.
XML Schema has uploaded at
http://www.oasis-open.org/committees/download.php/32575/EERP-Rating-WD03.xsd
, it added annotations to the relationship between ListOfRating and Credentials elements.
This issue can be closed.
Status changed to "CLOSED" on May 27th TC call.
Zero Obligations in SLA
This issue was raised during the SLA spec review at the TC meeting on
4/29/2009.
Carl Mattocks quested on meaning of zero Obligations in SLA
Andy Lee explained that in China there is case for zero SLA Obligations
Carl Mattocks suggested to explain USE CASE for this combination.
EERP-SLA
spec
editorial
Szu Chang
Szu Chang
N/A
Rex Brooks proposed Note: SLAObligations allows for a 0 number of
SLAObligations for conformance to business rules of China.
Carl Mattocks agreed to have explanation to avoid confusion.
New working draft (WD02) has uploaded at
http://www.oasis-open.org/committees/download.php/32560/BusinessServiceLevelAgreement-v1.0-spec-wd02.pdf with the following changes:
1. A note is added on line 315 to 316 to explain that there is case for
zero SLA Obligations.
2. An example of SLA without obligation is added on section 7.2, line 773
to 820.
New version of EERP-SLA schema has posted on
http://www.oasis-open.org/committees/download.php/32500/EERP-SLA-WD02.xsd
It is proposed to close this issue with above changes in place.
On May 13th TC call:
Issue #i011: It was a typo on spec. The old schema has one obligation;also something else. Since there are use cases in China that has zero obligation, both spec and schema have been changed.
Remain open due to the URL in this issues.xml points to wrong place. Szu to update correct URLs.including for the schema, and the issue can be closed.
CLOSE AFTER INSERTION OF CORRECT LINK TO PDF.
Status changed to "CLOSED" on May 27th TC call.
i012
Typo on Line 136, missing "?"
This issue was raised during the SLA spec review at the TC meeting on
4/29/2009.
Line 136 has a typo should be fixed and "?" should be added to the end
James Zhang noted that <SLAObligations> can have zero value as described
in section "SLAObligations". However in schema (line 136), it doesn't
indicate it is optional. We need to fix the schema for this.
EERP-SLA
spec
editorial
Szu Chang
Szu Chang
N/A
New working draft (WD02) has uploaded at
http://www.oasis-open.org/committees/download.php/32560/BusinessServiceLevelAgreement-v1.0-spec-wd02.pdf with the following changes:
The spec has changed on line 124 for:
<la:SLAObligations ...>sla:SLAObligationsType</sla:SLAObligations> ?
Line 147 to 148 for opetional element.
New version of EERP-SLA schema has posted on
http://www.oasis-open.org/committees/download.php/32500/EERP-SLA-WD02.xsd
The schema has changed SLAObligations element from 1 to 0 or 1
It is proposed to close this issue with above changes in place.
On May 13th TC call:
OPEN with the same reason as issue i011: due to the URL in this issues.xml points to wrong place. Szu to update correct URLs.including for the schema, and the issue can be closed.
CLOSE AFTER INSERTION OF CORRECT LINK TO PDF.
Status changed to "CLOSED" on May 27th TC call.
i011
Some editorial comments on draft bQoS spec
Issue #I008 on Some editorial comments on draft Rating spec also apply to
bQoS spec.
Open a new issue for tracking.
EERP-bQoS
spec
editorial
Szu Chang
Szu Chang
N/A
Insert the following text to all three spec per Rex Brooks:
"This document is a Work in Progress only and has not been extensively
reviewed. Comment on this document is encouraged. This document is one of
three closely related specifications, SOA-EERP Business Quality of Service
(bQoS), SOA-EERP Rating and SOA-EERP Service Level Agreement which need to
be understood in combination as a set."
Szu Chang proposed to remove the Conformance section for now. The section
can be added before public review.
Working draft WD03 at
http://www.oasis-open.org/committees/download.php/32450/BusinessQualityOfService-v1.0-spec-wd03.doc
has changed.
Related work on Page 1 and Status on page 2 has inserted the text per Rex
Brooks's sugguestion. The Conformance section has been removed.
Working draft WD03 at
http://www.oasis-open.org/committees/download.php/32450/BusinessQualityOfService-v1.0-spec-wd03.doc
has changed.
Related work on Page 1 and Status on page 2 has inserted the text per Rex
Brooks's sugguestion.
The Conformance section has been removed.
This issue can be closed.
On May 13th TC call:
ok, but conformance section reinserted.
Working Draft 04, uploaded at
http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/32576/BusinessQualityOfService-v1.0-spec-wd04.pdf, has the following changes:
The Conformance section has been inserted.
This issue can be closed.
Status changed to "CLOSED" on May 27th TC call.
i008
i014
Some editorial comments on draft SLA spec
Issue #I008 on Some editorial comments on draft Rating spec also apply to
bSLA spec.
Open a new issue for tracking.
EERP-SLA
spec
editorial
Szu Chang
Szu Chang
N/A
Insert the following text to all three spec per Rex Brooks:
"This document is a Work in Progress only and has not been extensively
reviewed. Comment on this document is encouraged. This document is one of
three closely related specifications, SOA-EERP Business Quality of Service
(bQoS), SOA-EERP Rating and SOA-EERP Service Level Agreement which need to
be understood in combination as a set."
Szu Chang proposed to remove the Conformance section for now. The section
can be added before public review.
Working draft WD02 at
http://www.oasis-open.org/committees/download.php/32560/BusinessServiceLevelAgreement-v1.0-spec-wd02.pdf
has changed.
Related work on Page 1 and Status on page 2 has inserted the text per Rex
Brooks's sugguestion.
The Conformance section has been removed.
This issue can be closed.
On May 13th TC call:
is the same (to i013), applied to a different document. Same
resolution: reinsert conformance section.
Working Draft 03, uploaded at
http://www.oasis-open.org/committees/download.php/32573/BusinessServiceLevelAgreement-v1.0-spec-wd03.pdf, has the following changes:
The Conformance section has been inserted.
This issue can be closed.
Status changed to "CLOSED" on May 27th TC call.
i008
i013
Repeated Text in the SLA obligation section
This issue was raised during the SLA spec review at the TC meeting on
5/13/2009 by
Carl Mattocks: in SBLA CD01, the SLA obligation section at 449-484 seems
to be repeated, in 490-517
Open a new issue for tracking.
EERP-SLA
spec
editorial
Szu Chang
Szu Chang
N/A
Line 449 is refer to CommittedCost, Like this:
447
/sla:SLAObligations/sla:Obligation/sla:ServiceLevelObjective/sla:CommittedCo
st/bqos:Unit
448 Number of unit is a optional element that includes a attribute of unit
of measurement uses
449 cbc:BaseUnitMeasureType. See /bqos:BQoSPrice/bqos:Price/bqos:Unit in
Section 3: BQoS
450 Price in EERP-bQoS Specification for more details.
451
/sla:SLAObligations/sla:Obligation/sla:ServiceLevelObjective/sla:CommittedCo
st/bqos:Amount
452 Amount element is a required element for the Committed Cost element. It
uses cbc:AmountType
453 from UBL that has a required currencyID attribute for currency code. See
454 /bqos:BQoSPrice/bqos:Price/bqos:Amount in Section 3: BQoS Price in
EERP-bQoS
455 Specification for more details.
Line 490 is refer to CommittedTime, like this:
490
/sla:SLAObligations/sla:Obligation/sla:ServiceLevelObjective/sla:CommittedTi
me/bqos:StartTime
491 StartTime is an optional element for the date and time to start the
service. It uses
492 udt:DateTimeType which is in Zulu time format. See
493 /bqos:BQoSPerformance/bqos:TimePeriod/bqos:StartTime in Section 4: BQoS
Performance in
494 EERP-bQoS Specification for more details.
495
/sla:SLAObligations/sla:Obligation/sla:ServiceLevelObjective/sla:CommittedTi
me/sla:CommittedCompleti
496 onTime
497 CommittedCompletionTime is an optional element for the date and time
for committed completion
498 time. It uses udt:DateTimeType which is in Zulu time format.
There are no repeated text found.
Propose to close the issue with no action.
Status changed to "CLOSED" with no action on May 27th TC call.
Including UBL Components in bQoS Schema
This issue was raised during the TC meeting on 5/13/2009. The issue is
should we poll into UBL or not?
Bill Cox: Concern is too much of UBL, which is huge. Don't understand
comment on URN. Bill proposed to close Issue I003, and open a new item on
UBL inclusion in general.
Issue I004 is similar.
.
EERP-bQoS
spec
design
Szu Chang
Szu Chang
N/A
Bill Cox: Will go from new to active when there's some comment/work done on it. Bill's concern is including large schemas (e.g. UBL) which may be a burden to processing on small devices.
Bill Cox: Proposal: Close. Rememeber we'll review the overall schema and quality characteristics at the next stage for the documents.
Status changed to "CLOSED" on May 27th TC call with the condition of review overall schema design at Action #A09-05-13-1.
i003
i004
SLAType missing anyAttribute
This issue was raised during by Zhili Zhang on 6/05/2009 per e-mail at
http://lists.oasis-open.org/archives/soa-eerp/200906/msg00003.html:
BQoSType and EERPRatingType have attribute "anyAttribute", but not
SLAType. Any reason?
EERP-SLA
schema
editorial
Zhili (James) Zhang
Szu Chang
N/A
"anyAttribute" has been added onto BSLAType.
The new SLA spec WD04 has uploaded at
http://www.oasis-open.org/committees/download.php/32837/BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf.
Line 158 - 160 has the changes.
The new schema EERP-SLA-WD04.xsd has uploaded at
http://www.oasis-open.org/committees/download.php/32839/EERP-SLA-WD04.xsd
This issue can be closed.
Status changed to "CLOSED" on June 10th TC call.
EERPRatingType should be RatingType
This issue was raised during by Zhili Zhang on 6/05/2009 per e-mail at
http://lists.oasis-open.org/archives/soa-eerp/200906/msg00003.html:
EERPRatingType has a prefix "EERP", but not the rest. I suggest removing the prefix "EERP" to make it consistent with others
.
EERP-Rating
schema
editorial
Zhili (James) Zhang
Szu Chang
N/A
EERPRatingType cannot be renamed to RatingType, as RatingType is already
used for children of the ListOfRating element. EERPRatingType has been
renamed to BusinessRatingType instead.
The new Rating spec WD04 has uploaded at
http://www.oasis-open.org/committees/download.php/32835/BusinessRating-v1.0-spec-wd04.pdf
The new schema EERP-Rating-WD04.xsd has uploaded at
http://www.oasis-open.org/committees/download.php/32840/EERP-Rating-WD04.xsd
In addition, to make the naming consistence, the EERPSLA, the root element
of BSLA, has also be renamed to BSLA, and EERPSLAType be renamed to
BSLAType.
The new SLA spec WD04 has uploaded at
http://www.oasis-open.org/committees/download.php/32837/BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf
The new schema EERP-SLA-WD04.xsd has uploaded at
http://www.oasis-open.org/committees/download.php/32839/EERP-SLA-WD04.xsd
This issue can be closed.
Per TC meeting on June 10, 2009, need to rename BusinessRating to BRating to make it consistent with other two specs before close this issue..
The new Rating spec WD05 has uploaded at
http://www.oasis-open.org/committees/download.php/32916/BusinessRating-v1.0-spec-wd05.pdf
The new schema EERP-Rating-WD05.xsd has uploaded at
http://www.oasis-open.org/committees/download.php/32917/EERP-Rating-WD05.xsd
Status changed to "CLOSED" after the WD05 is updated, that changed "BusinessRating" to "BRating".
Namespace for CD02
This issue was raised during by Zhili Zhang on 6/05/2009 per e-mail at
http://lists.oasis-open.org/archives/soa-eerp/200906/msg00003.html:
Declared namespace string has date "200903". Will it be changed to the month whenever the specs become CD? Also the schema locations are currently not accessible. For example http://docs.oasis-open.org/soa-eerp/eerp-bqos/200903/eerp-bqos.xsd. Will the links be accessible when publishing the CD?
.
EERP-bQoS
spec
editorial
Zhili (James) Zhang
Szu Chang
N/A
It is proposed to have the TC to make decision for where the current
namespace of 200903 should be changed or not for CD02.
Most other TCs use submit date in their namespace, instead of the final spec
publish date for their namespace.
On 06-10-2009 TC meeting, it has been decided to keep the namespace unchanged for the version one of these three specs.
Bill Cox will make sure the XSD files are accessible to the public when the spec is moved to Public Review Draft state.
Status changed to "CLOSED" on June 10th TC call.
Typo on SLA Namespace
This issue was raised during by Zhili Zhang on 6/05/2009 per e-mail at
http://lists.oasis-open.org/archives/soa-eerp/200906/msg00003.html:
Line 8 of spec http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/32573/BusinessServiceLevelAgreement-v1.0-spec-wd03.pdf, namespace string has a typo. It refers to namespace of ".../rt/...". The correct namespace should be ".../sla/...".
.
EERP-SLA
schema
editorial
Zhili (James) Zhang
Szu Chang
N/A
The namespace typo on line 8 has been fixed. The new SLA spec WD04 has
uploaded at
http://www.oasis-open.org/committees/download.php/32837/BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf
This issue can be closed.
Status changed to "CLOSED" on June 10th TC call.
Update "Document Type" and "Created On" on xsd
This issue was raised during by Zhili Zhang on 6/05/2009 per e-mail at
http://lists.oasis-open.org/archives/soa-eerp/200906/msg00003.html:
"Document Type" and "Created On" (first few commented lines in EERP-bQoS-wd02.xsd) are not updated
.
EERP-bQoS
schema
editorial
Zhili (James) Zhang
Szu Chang
N/A
The Document Type has changed to "EERP-bQoS Working Draft 04 (WD04)" and
Created On has changed to "06/08/2009" on the new schema
EERP-bQoS-WD04.xsd. It has been uploaded at
http://www.oasis-open.org/committees/download.php/32838/EERP-bQoS-WD04.xsd
There are no spec changes on this issue. The issue can be closed.
Status changed to "CLOSED" on June 10th TC call.
Performance:QualityAssertion
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
EERP-bQoS
spec
design
Rex Brooks
Szu Chang
N/A
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.
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 will go back through. Our current target is a new WD that can become Committee Draft 02.
Rating Issue: QualityAssertionEvaluation
(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
EERP-Rating
spec
editorial
Rex Brooks
Szu Chang
N/A
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.
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).
SLA Spec:Research Question
Have we checked this with OASIS Mgt and Jamie Clark in
particular?
I'm concerned that we are addressing international legal issues and I
think we should check on this with OASIS Mgt and Legal resources.
Cheers,
Rex
EERP-SLA
spec
admin
Rex Brooks
Bill Cox
N/A
General question under SLA, which is a legal document and binding. Have we checked with OASIS staff on how to handle things like this?
ACTION Bill Cox and Rex Brooks to address and make suggestions.
Action: i024 Keep Open.
SLA Spec: CIQ Reuse
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
EERP-SLA
spec
design
Rex Brooks
Szu Chang
N/A
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.
Rex: Similar, could lead to a change. We should review the CIQ specification for parties. In SLA we are defining parties, not only name and address. Reusing an existing OASIS Committee Specification. I have already used it in Emergency Management. It is not perfect, but it is moving toward a standard for these issues. They have already vetted it. CIQ originally stood for "Customer Information Quality", not it is "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 specifications as well.
Action: i025 Keep Open. Probably not for next CD.
BQoS: Various Editorial 1
These editorial corrections are referenced to
http://www.oasis-open.org/committees/download.php/32576/BusinessQualityOfService-v1.0-spec-wd04.pdf
but apply to all three specifications; line numbers are in BQOS.
(1) Change "Bill Cox" to "William Cox" wherever it occurs, under
"Chairs" and line 457.
(2) Remove extra blank lines between paragraphs--the template style
spaces between paragraphs. For example, after all other changes are
completed remove lines 49, 59, 65, 71, 73, 76, etc.
(3) Under related work on title page delete " as a set." This is redundant.
(4) Change abstract on title page to "This document specifies the XML
vocabulary for business quality of service (bQoS), one of three
specifications for end-to-end resource planning (EERP). Business quality
of service describes the business-related characteristics or attributes
of a service." Similar for the other two specifications.
(5) Structure documents per the current OASIS specification template at
http://docs.oasis-open.org/templates/OASISSpecificationTemplateV3.2.dot
. Some issues are the order of the start, e.g., The brief introduction
is followed by 1.1 Terminology then 1.2 Normative References, and so
forth. See, for example,
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/200707/AS4-profile-cd-01.pdf
(6) Line 25 delete.
(7) List of participants - I'll have to check in detail. Eliminate
commas after each name.
EERP-bQoS
spec
editorial
William Cox
Szu Chang
N/A
Correct as indicated.
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 Item 1 to item 7 of issue with exception of item #5 only change
partially.
Reasons: Many OASIS standards do not follow the template completely. See,
for example,
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/ws-securitypolicy.pdf and
http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-1.1-spec-os.pdf
It is proposed to close the issue with above changes.
This is OK, except that item 5 must be corrected.
For a public review one criterion is that the document follow the CURRENT OASIS Template.
The examples cited are older, and besides we need to follow the current template.
Proposal: Meet the OASIS Specification Template as raised in sub-issue 5.
bill
Szu: Pending close when it meets the template outline.
Action: i026 Proposal 5 (follow the template). No objections.
New working Draft WD06 uploaded at
http://www.oasis-open.org/committees/document.php?document_id=33226 and it
fixed the template problem.
This issue changed from pending close to Closed.
Rating: Various Editorial 1
These editorial corrections are referenced to
http://www.oasis-open.org/committees/download.php/32576/BusinessQualityOfService-v1.0-spec-wd04.pdf
but apply to all three specifications; line numbers are in BQOS.
(1) Change "Bill Cox" to "William Cox" wherever it occurs, under
"Chairs" and line 457.
(2) Remove extra blank lines between paragraphs--the template style
spaces between paragraphs. For example, after all other changes are
completed remove lines 49, 59, 65, 71, 73, 76, etc.
(3) Under related work on title page delete " as a set." This is redundant.
(4) Change abstract on title page to "This document specifies the XML
vocabulary for business quality of service (bQoS), one of three
specifications for end-to-end resource planning (EERP). Business quality
of service describes the business-related characteristics or attributes
of a service." Similar for the other two specifications.
(5) Structure documents per the current OASIS specification template at
http://docs.oasis-open.org/templates/OASISSpecificationTemplateV3.2.dot
. Some issues are the order of the start, e.g., The brief introduction
is followed by 1.1 Terminology then 1.2 Normative References, and so
forth. See, for example,
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/200707/AS4-profile-cd-01.pdf
(6) Line 25 delete.
(7) List of participants - I'll have to check in detail. Eliminate
commas after each name.
EERP-Rating
schema
editorial
William Cox
Szu Chang
N/A
Correct as indicated.
SOA_EERP Business Rating spec version 1.0 Working Draft 06 (WD06) uploaded
http://www.oasis-open.org/committees/download.php/33070/BusinessRating-v1.0-spec-wd06.pdf
Same as Issue I026, fixed Item 1 to item 7 of issue with exception of item
#5 only change partially.
Reasons: Many OASIS standards do not follow the template completely. See,
for example,
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/ws-securitypolicy.pdf
and
http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-1.1-spec-os.pdf
It is proposed to close the issue with above changes.
Propose accepting Proposal 1
Action: i027 Proposal 1.
New working Draft WD06 uploaded at
www.oasis-open.org/committees/download.php/33230/BusinessRating-v1.0-spec-wd07.pdf and it fixed the template problem.
Same as, I026, this issue changed from pending close to Closed.
BSLA: Various Editorial 1
These editorial corrections are referenced to
http://www.oasis-open.org/committees/download.php/32576/BusinessQualityOfService-v1.0-spec-wd04.pdf
but apply to all three specifications; line numbers are in BQOS.
(1) Change "Bill Cox" to "William Cox" wherever it occurs, under
"Chairs" and line 457.
(2) Remove extra blank lines between paragraphs--the template style
spaces between paragraphs. For example, after all other changes are
completed remove lines 49, 59, 65, 71, 73, 76, etc.
(3) Under related work on title page delete " as a set." This is redundant.
(4) Change abstract on title page to "This document specifies the XML
vocabulary for business quality of service (bQoS), one of three
specifications for end-to-end resource planning (EERP). Business quality
of service describes the business-related characteristics or attributes
of a service." Similar for the other two specifications.
(5) Structure documents per the current OASIS specification template at
http://docs.oasis-open.org/templates/OASISSpecificationTemplateV3.2.dot
. Some issues are the order of the start, e.g., The brief introduction
is followed by 1.1 Terminology then 1.2 Normative References, and so
forth. See, for example,
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/200707/AS4-profile-cd-01.pdf
(6) Line 25 delete.
(7) List of participants - I'll have to check in detail. Eliminate
commas after each name.
EERP-SLA
schema
editorial
William Cox
Szu Chang
N/A
Correct as indicated.
SOA-EERP BusinessServiceLevelAgreement v1.0 spec working draft 05 (WD05)
is uploaded at:
http://www.oasis-open.org/committees/download.php/33073/BusinessServiceLevelAgreement-v1.0-spec-wd05.pdf
Fixed the issue same as I026.
This issue should be closed.
OK to close pending review
bill cox
Szu proposes same as i026. No objection to Proposal 1.
Action: i028 Proposal 1.
New working Draft WD06 uploaded at
www.oasis-open.org/committees/download.php/33244/BusinessServiceLevelAgreement-v1.0-spec-wd06.pdf and it fixed the template problem.
This issue changed from pending close to Closed.
BQoS Various Editorial 2
These editorial corrections are referenced to
http://www.oasis-open.org/committees/download.php/32576/BusinessQualityOfService-v1.0-spec-wd04.pdf
but apply to all three specifications; line numbers are in BQOS.
(1) First two lines of Status on title page should be deleted.
(2) Rewrite Introduction. Suggested text:
"This documnent is the specification for Business Quality of Service for
End-to-End Resource planning, an XML vocabuly by which a business
application may communicate selected characteristics of the service it
provides." The suggested text applies to BQOS; similar text will be
suggested in other issues for the rating and sla.
(3) A longer introduction describing EERP in general, and relating the
three specifications, would be desirable in all three documents.
(4) Delete "All text is normative unless otherwise indicated." This is
in square brackets in the specification template at
http://docs.oasis-open.org/templates/OASISSpecificationTemplateV3.2.dot
and should not appear in the final document.
(5) Section 1.1, namespaces, should be after Non-Normative references at
the start of Section 2.
(6) In BQOS line 66-67 change "standard" to "specification" and change
"model, and bQoS should" to "model. bQoS should".
(7) Generally for section headings in all of the specification (see in
BQOS lines 150, 205, 311) make the section heading the same as the
element type, e.g. line 150 in BQOS should read "BQoSPrice" with no spaces.
EERP-bQoS
spec
editorial
William Cox
Szu Chang
N/A
i026
Correct as indicated.
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 Item 1 to item 7 of this issue.
It is proposed to close the issue with above changes.
OK to close pending review of item (2).
bill cox
Same treatment.
Action: i029 Proposal 1.
Rating Various Editorial 2
These editorial corrections are referenced to
http://www.oasis-open.org/committees/download.php/32576/BusinessQualityOfService-v1.0-spec-wd04.pdf
but apply to all three specifications; line numbers are in BQOS.
(1) First two lines of Status on title page should be deleted.
(2) Rewrite Introduction. Suggested text:
"This documnent is the specification for Business Quality of Service for
End-to-End Resource planning, an XML vocabuly by which a business
application may communicate selected characteristics of the service it
provides." The suggested text applies to BQOS; similar text will be
suggested in other issues for the rating and sla.
(3) A longer introduction describing EERP in general, and relating the
three specifications, would be desirable in all three documents.
(4) Delete "All text is normative unless otherwise indicated." This is
in square brackets in the specification template at
http://docs.oasis-open.org/templates/OASISSpecificationTemplateV3.2.dot
and should not appear in the final document.
(5) Section 1.1, namespaces, should be after Non-Normative references at
the start of Section 2.
(6) In BQOS line 66-67 change "standard" to "specification" and change
"model, and bQoS should" to "model. bQoS should".
(7) Generally for section headings in all of the specification (see in
BQOS lines 150, 205, 311) make the section heading the same as the
element type, e.g. line 150 in BQOS should read "BQoSPrice" with no spaces.
EERP-Rating
spec
editorial
William Cox
Szu Chang
N/A
i027
Correct as indicated.
SOA_EERP Business Rating spec version 1.0 Working Draft 06 (WD06) uploaded
http://www.oasis-open.org/committees/download.php/33070/BusinessRating-v1.0-spec-wd06.pdf
It fixed Item 1 to item 7 of the issue.
It is proposed to close the issue with above changes.
OK to close pending review of item (2).
bill cox
Correction --
NOT OK to close - more than 2 are not addressed. The outline does not meet the current OASIS template.
bill cox
Action: i030 Close; Bill validate that item 3 is satisfactory
BSLA Various Editorial 2
These editorial corrections are referenced to
http://www.oasis-open.org/committees/download.php/32576/BusinessQualityOfService-v1.0-spec-wd04.pdf
but apply to all three specifications; line numbers are in BQOS.
(1) First two lines of Status on title page should be deleted.
(2) Rewrite Introduction. Suggested text:
"This documnent is the specification for Business Quality of Service for
End-to-End Resource planning, an XML vocabuly by which a business
application may communicate selected characteristics of the service it
provides." The suggested text applies to BQOS; similar text will be
suggested in other issues for the rating and sla.
(3) A longer introduction describing EERP in general, and relating the
three specifications, would be desirable in all three documents.
(4) Delete "All text is normative unless otherwise indicated." This is
in square brackets in the specification template at
http://docs.oasis-open.org/templates/OASISSpecificationTemplateV3.2.dot
and should not appear in the final document.
(5) Section 1.1, namespaces, should be after Non-Normative references at
the start of Section 2.
(6) In BQOS line 66-67 change "standard" to "specification" and change
"model, and bQoS should" to "model. bQoS should".
(7) Generally for section headings in all of the specification (see in
BQOS lines 150, 205, 311) make the section heading the same as the
element type, e.g. line 150 in BQOS should read "BQoSPrice" with no spaces.
EERP-SLA
spec
editorial
William Cox
Szu Chang
N/A
i028
Correct as indicated.
SOA-EERP BusinessServiceLevelAgreement v1.0 spec working draft 05 (WD05)
is uploaded at:
http://www.oasis-open.org/committees/download.php/33073/BusinessServiceLevelAgreement-v1.0-spec-wd05.pdf
The issue is fixed and can be closed.
NOT OK to close -- at least items 3 and 5 have not been addressed.
Futher review required. Item 5 is critical as we move to public review.
bill cox
Action: i031 Close; Bill validate that item 3 is satisfactory
BQOS Editorial
Suggested editorial changes will be posted as edited version of
http://www.oasis-open.org/apps/org/workgroup/soa-eerp/download.php/32574/BusinessQualityOfService-v1.0-spec-wd04.doc
(uploaded as
http://www.oasis-open.org/committees/download.php/33018/BusinessQualityOfService-v1.0-spec-wd04-wtc.doc
) with changes tracked and comments included. Substantive issues will be
posted separately.
.
EERP-bQoS
spec
editorial
William Cox
Szu Chang
N/A
Address editorial suggestions
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 accepted all changes and fixed the comments. See
http://www.oasis-open.org/committees/download.php/33061/BusinessQualityOfService-v1.0-spec-wd05-withChanges.doc
for more details of changes.
It is proposed to close the issue with above changes.
OK to close pending review of changes.
bill cox
Propose to close with proposal.
Action: i032 Closed.
BQoS Namespaces, normative references, and rationale
TThis applies to all three specifications under review.
The normative list of namespaces cites CEFACT ccts but does not list it
in the normative references.
The reasoning for the choice of namespaces, and in particular whether
the UBL namespaces include ccts, is not clear. Address whether the CEFAC
T namespace is included directly and within UBL, and briefly justify the
choice.
EERP-bQoS
spec
design
William Cox
Szu Chang
N/A
Add normative reference for ccts schema as needed.
Add non-normative text in Appendix B to explain the choice of
namespaces and schemas used.
(Namespaces) Leave Open. Szu: To be fixed. Bill: i034 i035 (?) the same.
Action: i033, i034, i035 Keep Open.
New working Draft WD06 uploaded at
http://www.oasis-open.org/committees/document.php?document_id=33226 and it
added the CEFACT reference on Line # 41-42 and reference on Table 1 on line
# 39.
This issue can be closed.
i034
i035
Rating - Namespaces, normative references, and rationale
TThis applies to all three specifications under review.
The normative list of namespaces cites CEFACT ccts but does not list it
in the normative references.
The reasoning for the choice of namespaces, and in particular whether
the UBL namespaces include ccts, is not clear. Address whether the CEFAC
T namespace is included directly and within UBL, and briefly justify the
choice.
EERP-Rating
spec
design
William Cox
Szu Chang
N/A
Add normative reference for ccts schema as needed.
Add non-normative text in Appendix B to explain the choice of
namespaces and schemas used.
(Namespaces) Leave Open. Szu: To be fixed. Bill: i034 i035 (?) the same.
Action: i033, i034, i035 Keep Open.
New working Draft WD06 uploaded at
www.oasis-open.org/committees/download.php/33230/BusinessRating-v1.0-spec-wd07.pdf and it added the CEFACT reference on Line # 37-38 and reference on
Table 1 on line # 88. The Reference and usage of UBL is documented on line
# 71-74.
This issue can be closed.
i033
i035
BSLA - Namespaces, normative references, and rationale
TThis applies to all three specifications under review.
The normative list of namespaces cites CEFACT ccts but does not list it
in the normative references.
The reasoning for the choice of namespaces, and in particular whether
the UBL namespaces include ccts, is not clear. Address whether the CEFAC
T namespace is included directly and within UBL, and briefly justify the
choice.
EERP-SLA
spec
design
William Cox
Szu Chang
N/A
Add normative reference for ccts schema as needed.
Add non-normative text in Appendix B to explain the choice of
namespaces and schemas used.
There is only one reference on "protocol" on this BSLA spec and has been
already addressed on issue # I031.
The issue should be closed due to duplicated.
This is NOT OK to close - this is a substantive issue, and i031 is editorial. When that change is made, that part of i031 can be closed as well as this one.
The issue needs to be addressed.
bill
(Namespaces) Leave Open. Szu: To be fixed. Bill: i034 i035 (?) the same.
Action: i033, i034, i035 Keep Open.
New working Draft WD06
www.oasis-open.org/committees/download.php/33244/BusinessServiceLevelAgreement-v1.0-spec-wd06.pdf and it added the CEFACT reference on Line # 43-45 and
reference on Table 1 on line # 97. The Reference and usage of UBL is
documented on line # 78-81.
This issue can be closed.
i033
i034
BQoS - Unrecognized Attributes and Extensibility
This issue applies to
BusinessQualityOfService-v1.0-spec-wd04.pdf
BusinessRating-v1.0-spec-wd05.pdf
BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf
Examples are from BQOS. See lines 130, 137, 143, 146, 149, 190, 284,
342, 352, 355, 447. This addresses overall issues for management and
extensibility using the any mechanism.
(1) The attributes are also called parameters; is this correct?
(2) The SHOULD behavior will allow an implementation to silently ignore
unrecognized attributes. If this is the intended behavior, MAY might be
the right keyword, but it's not at all clear that a fault should be
generated for unrecognized attributes. Interoperable applications could
instead ignore unrecognized attributes, or maintain "understood
attribute profiles."
(3) Similar management issues have registered or otherwise predefined
specific characteristics or attributes; some of these are defined, but
the interoperability and attribute managements are not addressed in the
specifications.
EERP-bQoS
spec
design
William Cox
Szu Chang
N/A
(a) Make terminology consistent; if the inconsistency is correct, state
reason in normative text.
(b) Address interoperability concerns for multiple implementations,
particularly ones that do not recognize the same sets of attributes.
Explain in normative or non-normative text why the specified behavior is
necessary or desirable for interoperation.
(c) Justify choices made in Appendix B or other non-normative text.
1. All text of "Unrecognized attributes SHOULD cause a fault." will be
changed to "Unrecognized attributes MAY cause a fault or be silently
ignored."
2. All text of "Unrecognized parameters SHOULD cause a fault." will be
changed to "Unrecognized elements MAY cause a fault or be silently ignored."
3. All text of "different (extensible) elements/parameters to be specified
in the future." will be changed to "different (extensible) elements to be
specified in the future."
Interoperable applications could opt to ignore unrecognized attributes and
elements.
This is good. There is, however an effect on the conformance section (subject of other issues).
bill cox
i036: Comment that we will have profiling and conformance issues, but this issue is addressed. No objection. i037 and i038 similar.
Action: i036, i037, i038 Closed with comment.
i037
i038
Rating - Unrecognized Attributes and Extensibility
This issue applies to
BusinessQualityOfService-v1.0-spec-wd04.pdf
BusinessRating-v1.0-spec-wd05.pdf
BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf
Examples are from BQOS. See lines 130, 137, 143, 146, 149, 190, 284,
342, 352, 355, 447. This addresses overall issues for management and
extensibility using the any mechanism.
(1) The attributes are also called parameters; is this correct?
(2) The SHOULD behavior will allow an implementation to silently ignore
unrecognized attributes. If this is the intended behavior, MAY might be
the right keyword, but it's not at all clear that a fault should be
generated for unrecognized attributes. Interoperable applications could
instead ignore unrecognized attributes, or maintain "understood
attribute profiles."
(3) Similar management issues have registered or otherwise predefined
specific characteristics or attributes; some of these are defined, but
the interoperability and attribute managements are not addressed in the
specifications.
EERP-Rating
spec
design
William Cox
Szu Chang
N/A
(a) Make terminology consistent; if the inconsistency is correct, state
reason in normative text.
(b) Address interoperability concerns for multiple implementations,
particularly ones that do not recognize the same sets of attributes.
Explain in normative or non-normative text why the specified behavior is
necessary or desirable for interoperation.
(c) Justify choices made in Appendix B or other non-normative text.
same as Isuue I036,
1. All text of "Unrecognized attributes SHOULD cause a
fault." will be changed to "Unrecognized attributes MAY cause a fault or be
silently ignored."
2. All text of "Unrecognized parameters SHOULD cause a fault." will be
changed to "Unrecognized elements MAY cause a fault or be silently ignored."
3. All text of "different (extensible) elements/parameters to be specified
in the future." will be changed to "different (extensible) elements to be
specified in the future."
Interoperable applications could opt to ignore unrecognized attributes and
elements.
This is good. There is, however an effect on the conformance section (subject of other issues).
bill cox
i036: Comment that we will have profiling and conformance issues, but this issue is addressed. No objection. i037 and i038 similar.
Action: i036, i037, i038 Closed with comment.
i036
i038
BSLA - Unrecognized Attributes and Extensibility
This issue applies to
BusinessQualityOfService-v1.0-spec-wd04.pdf
BusinessRating-v1.0-spec-wd05.pdf
BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf
Examples are from BQOS. See lines 130, 137, 143, 146, 149, 190, 284,
342, 352, 355, 447. This addresses overall issues for management and
extensibility using the any mechanism.
(1) The attributes are also called parameters; is this correct?
(2) The SHOULD behavior will allow an implementation to silently ignore
unrecognized attributes. If this is the intended behavior, MAY might be
the right keyword, but it's not at all clear that a fault should be
generated for unrecognized attributes. Interoperable applications could
instead ignore unrecognized attributes, or maintain "understood
attribute profiles."
(3) Similar management issues have registered or otherwise predefined
specific characteristics or attributes; some of these are defined, but
the interoperability and attribute managements are not addressed in the
specifications.
EERP-SLA
spec
design
William Cox
Szu Chang
N/A
(a) Make terminology consistent; if the inconsistency is correct, state
reason in normative text.
(b) Address interoperability concerns for multiple implementations,
particularly ones that do not recognize the same sets of attributes.
Explain in normative or non-normative text why the specified behavior is
necessary or desirable for interoperation.
(c) Justify choices made in Appendix B or other non-normative text.
same as Isuue I036:
1. All text of "Unrecognized attributes SHOULD cause a
fault." will be changed to "Unrecognized attributes MAY cause a fault or be
silently ignored."
2. All text of "Unrecognized parameters SHOULD cause a fault." will be
changed to "Unrecognized elements MAY cause a fault or be silently ignored."
3. All text of "different (extensible) elements/parameters to be specified
in the future." will be changed to "different (extensible) elements to be
specified in the future."
Interoperable applications could opt to ignore unrecognized attributes and
elements.
This is good. There is, however an effect on the conformance section (subject of other issues).
bill cox
i036: Comment that we will have profiling and conformance issues, but this issue is addressed. No objection. i037 and i038 similar.
Action: i036, i037, i038 Closed with comment.
i036
i037
BQoS - Protocol or Vocabulary
This issue applies to
BusinessQualityOfService-v1.0-spec-wd04.pdf
BusinessRating-v1.0-spec-wd05.pdf
BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf
Example is from BQOS. See line 3, which ways "...End-to-End Resource
Planning, a protocol..."
These specifications appear to specify an XML vocabulary for message
payloads or information exchange, rather than a protocol to define the
interactions.
EERP-bQoS
spec
design
William Cox
Szu Chang
N/A
Change references to "protocol" to describe instead an XML vocabulary
for information exchange. Address in the introductions for each
specification.
If a protocol is intended to be defined, perhaps creating a separate
protocol specification would be in order, but I believe that the purpose
is better served by changing the descriptions to state explicitly that a
protocol is NOT being defined.
There is only one reference on "protocol" on this bQoS spec and has been
already addressed on issue # I029.
The issue should be closed due to duplicated.
OK with this, however i029 proposal 2 has problems. Proposal 1 of that is fine.
bill cox
Correction - it is NOT OK with me to close this issue, as the referenced issue is editorial, not technical.
bill cox
Szu: has been fixed in i029. Bill: Vocabulary or protocol? This is a big issue. Zhili: If we introduce a protocol it’s more work, so he prefers not to do it. Rex: This is closer to a vocabulary than a protocol. Bill: Rex, what do we need to make it a vocabulary? (b) is not what we want to do. Szu: proposes to decide for now that we have two things. Rex: My initial comment adding a quality assertion begins to step into the protocol arena—an exchange, even if not explicit, is made.
Bill: I suggest we close these three and create a new issue on protocols, vocabularies, and the work of the TC.
ACTION Bill Send New Issue for protocol versus vocabulary. Zhili suggests that the new issue be called “How to address the protocol aspect(s) of SOA-EERP.
Action: i039, i040, i041 Closed. New issue will address the bigger point.
i040
i041
Rating - Protocol or Vocabulary
This issue applies to
BusinessQualityOfService-v1.0-spec-wd04.pdf
BusinessRating-v1.0-spec-wd05.pdf
BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf
Example is from BQOS. See line 3, which ways "...End-to-End Resource
Planning, a protocol..."
These specifications appear to specify an XML vocabulary for message
payloads or information exchange, rather than a protocol to define the
interactions.
EERP-Rating
spec
design
William Cox
Szu Chang
N/A
Change references to "protocol" to describe instead an XML vocabulary
for information exchange. Address in the introductions for each
specification.
If a protocol is intended to be defined, perhaps creating a separate
protocol specification would be in order, but I believe that the purpose
is better served by changing the descriptions to state explicitly that a
protocol is NOT being defined..
There is only one reference on "protocol" on this bQoS spec and has been
already addressed on issue # I030.
The issue should be closed due to duplicated.
This refers to Rating, not BQoS.
This is NOT OK to close as duplicate, as this is the substantive technical issue, not the editorial issue cited in i030.
bill cox
Szu: has been fixed in i029. Bill: Vocabulary or protocol? This is a big issue. Zhili: If we introduce a protocol it’s more work, so he prefers not to do it. Rex: This is closer to a vocabulary than a protocol. Bill: Rex, what do we need to make it a vocabulary? (b) is not what we want to do. Szu: proposes to decide for now that we have two things. Rex: My initial comment adding a quality assertion begins to step into the protocol arena—an exchange, even if not explicit, is made.
Bill: I suggest we close these three and create a new issue on protocols, vocabularies, and the work of the TC.
ACTION Bill Send New Issue for protocol versus vocabulary. Zhili suggests that the new issue be called “How to address the protocol aspect(s) of SOA-EERP.
Action: i039, i040, i041 Closed. New issue will address the bigger point.
i039
i041
BSLA - Protocol or Vocabulary
This issue applies to
BusinessQualityOfService-v1.0-spec-wd04.pdf
BusinessRating-v1.0-spec-wd05.pdf
BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf
Example is from BQOS. See line 3, which ways "...End-to-End Resource
Planning, a protocol..."
These specifications appear to specify an XML vocabulary for message
payloads or information exchange, rather than a protocol to define the
interactions.
EERP-SLA
spec
design
William Cox
Szu Chang
N/A
Change references to "protocol" to describe instead an XML vocabulary
for information exchange. Address in the introductions for each
specification.
If a protocol is intended to be defined, perhaps creating a separate
protocol specification would be in order, but I believe that the purpose
is better served by changing the descriptions to state explicitly that a
protocol is NOT being defined..
There is only one reference on "protocol" on this bSLA spec and has been
already addressed on issue # I031.
The issue should be closed due to duplicated.
OK to close.
bill cox
Szu: has been fixed in i029. Bill: Vocabulary or protocol? This is a big issue. Zhili: If we introduce a protocol it’s more work, so he prefers not to do it. Rex: This is closer to a vocabulary than a protocol. Bill: Rex, what do we need to make it a vocabulary? (b) is not what we want to do. Szu: proposes to decide for now that we have two things. Rex: My initial comment adding a quality assertion begins to step into the protocol arena—an exchange, even if not explicit, is made.
Bill: I suggest we close these three and create a new issue on protocols, vocabularies, and the work of the TC.
ACTION Bill Send New Issue for protocol versus vocabulary. Zhili suggests that the new issue be called “How to address the protocol aspect(s) of SOA-EERP.
Action: i039, i040, i041 Closed. New issue will address the bigger point.
i039
i040
BQoS - Zulu Time should be UTC and Needs Reference
This issue applies to
BusinessQualityOfService-v1.0-spec-wd04.pdf
BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf
See BQOS lines 250, 301, and BLSA lines 495, 501, 527, 530.
See also e.g. http://en.wikipedia.org/wiki/Coordinated_Universal_Time
"...all use UTC (also colloquially referred to as "Zulu Time") to avoid
confusion about time zones and daylight saving time
<http://en.wikipedia.org/wiki/Daylight_saving_time>" and
http://hurricanes.noaa.gov/zulu-utc.html "NOAA satellites use Zulu Time
or Coordinated Universal Time (UTC) as their time reference. The
satellite images that appear on NOAA's Web sites are stamped in Zulu time."
The proper non-colloquial usage is "UTC". The expression is typically
done with ISO8601, explained at
http://www.iso.org/iso/support/faqs/faqs_widely_used_standards/widely_used_standards_other/date_and_time_format.htm
and http://www.cl.cam.ac.uk/~mgk25/iso-time.html . The usage in line 301
is consistent with ISO8601, but the colloquial terminology is not.
EERP-bQoS
spec
design
William Cox
Szu Chang
N/A
Change text to indicate UTC.
Provide normative reference to ISO8601. (see OASIS Artifact Naming
Guidelines).
Szu: Keep these open. Bill: Accept Szu’s proposal 1. No objection
Action: i042, i043, i044: Accept Proposal 1, close after completed and verified.
New working Draft WD06 uploaded at
http://www.oasis-open.org/committees/document.php?document_id=33226.
It added the ISO8601 reference on Line # 36-40 and reference UTC on line #
237. Line 3 $04 also changed to UTC time.
This issue can be closed.
i043
BSLA - Zulu Time should be UTC and Needs Reference
This issue applies to
BusinessQualityOfService-v1.0-spec-wd04.pdf
BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf
See BQOS lines 250, 301, and BLSA lines 495, 501, 527, 530.
See also e.g. http://en.wikipedia.org/wiki/Coordinated_Universal_Time
"...all use UTC (also colloquially referred to as "Zulu Time") to avoid
confusion about time zones and daylight saving time
<http://en.wikipedia.org/wiki/Daylight_saving_time>" and
http://hurricanes.noaa.gov/zulu-utc.html "NOAA satellites use Zulu Time
or Coordinated Universal Time (UTC) as their time reference. The
satellite images that appear on NOAA's Web sites are stamped in Zulu time."
The proper non-colloquial usage is "UTC". The expression is typically
done with ISO8601, explained at
http://www.iso.org/iso/support/faqs/faqs_widely_used_standards/widely_used_standards_other/date_and_time_format.htm
and http://www.cl.cam.ac.uk/~mgk25/iso-time.html . The usage in line 301
is consistent with ISO8601, but the colloquial terminology is not.
EERP-SLA
spec
design
William Cox
Szu Chang
N/A
Change text to indicate UTC.
Provide normative reference to ISO8601. (see OASIS Artifact Naming
Guidelines).
Szu: Keep these open. Bill: Accept Szu’s proposal 1. No objection
Action: i042, i043, i044: Accept Proposal 1, close after completed and verified.
New working Draft WD06 uploaded at
www.oasis-open.org/committees/download.php/33244/BusinessServiceLevelAgreement-v1.0-spec-wd06.pdf
.
It added the ISO8601 reference on Line # 39-43 and reference UTC on line #
460, 466, 488 and 491.
This issue can be closed.
i042
BQOS Example
The example in section 6.1 should be expanded with other alternatives
and a different currency. The example is a good choice, but there should
be a complete example with different options and only Latin characters.
I suggest using CHF or other currency for the example.
EERP-bQoS
spec
editorial
William Cox
Szu Chang
N/A
Insert additional example as described.
Szu: Keep these open. Bill: Accept Szu’s proposal 1. No objection
Action: i042, i043, i044: Accept Proposal 1, close after completed and verified.
New working Draft WD06 uploaded at
http://www.oasis-open.org/committees/document.php?document_id=33226 and it
added a new example on Line # 400-431.
This issue can be closed.
BQoS - Conformance Issues 1
This issue applies to
BusinessQualityOfService-v1.0-spec-wd04.pdf
BusinessRating-v1.0-spec-wd05.pdf
BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf
Examples are from BQOS. See lines 427-448
This addresses overall issues for conformance that I believe are in all
three specifications. Line numbers from BQOS.
(1) Line 432 - which "table above"?
(2) Many of the conformance clauses reference SHOULD and MAY statements.
It is not clear what MUST be done to conform.
(3) Another issue, Unrecognized Attributes and Extensibility, points out
interoperability issues with the conformance and descriptions as
provided. The choices should be conscious and clearly spelled out and
justified.
(4) The conformance section references "OPTIONAL messages" (line 446 and
elsewhere). What is meant by "message"? And who does or does not
"support" it? This reads as if it were copied from a protocol spec, not
a vocabulary spec.
EERP-bQoS
spec
design
William Cox
Szu Chang
N/A
(a) Make terminology consistent; if the inconsistency is correct, state
reason in normative text.
(b) Address interoperability concerns for multiple implementations,
particularly ones that do not recognize the same sets of attributes.
Explain in normative or non-normative text why the specified behavior is
necessary or desirable for interoperation.
(c) Justify choices made in Appendix B or other non-normative text. The
range of choices must be described, as well as the rationale for the
particular choices.
(d) Correct wording referring to messages to "instances". Clarify who or
what supports what behavior; see related issue on extensibility.
Fixed item #1 and changed last paragraph to the following:
"This specification defines a number of extensions; compliant services are
NOT REQUIRED to implement those extensions defined in this specification.
However, if a service implements an aspect of the specification, it MUST
comply with the requirements specified (e.g. related "MUST" statements). If
an implementation silently ignore unrecognized attributes where any
attribute is allowed, or silently ignore unrecognized elements where any
element is allowed, should be considered as interoperable implementation."
There are no more SHOULD and MAY in the Conformance section, and no more
"OPTIONAL messages". Item #2, 3 and 4 of this issue should be addressed by
the above changes.
The issue of the conformance section is addressed elsewhere (or will be), so it's OK with me to close this with the stated solution. Proposal 1 is a better choice in my opinion.
bill
Discussion. OK to close; will have conformance issue in i053.
Action: i045, i046, i047 Accept Proposal, close after completed and verified.
i036
i046
i047
Rating - Conformance Issues 1
This issue applies to
BusinessQualityOfService-v1.0-spec-wd04.pdf
BusinessRating-v1.0-spec-wd05.pdf
BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf
Examples are from BQOS. See lines 427-448
This addresses overall issues for conformance that I believe are in all
three specifications. Line numbers from BQOS.
(1) Line 432 - which "table above"?
(2) Many of the conformance clauses reference SHOULD and MAY statements.
It is not clear what MUST be done to conform.
(3) Another issue, Unrecognized Attributes and Extensibility, points out
interoperability issues with the conformance and descriptions as
provided. The choices should be conscious and clearly spelled out and
justified.
(4) The conformance section references "OPTIONAL messages" (line 446 and
elsewhere). What is meant by "message"? And who does or does not
"support" it? This reads as if it were copied from a protocol spec, not
a vocabulary spec.
EERP-Rating
spec
design
William Cox
Szu Chang
N/A
(a) Make terminology consistent; if the inconsistency is correct, state
reason in normative text.
(b) Address interoperability concerns for multiple implementations,
particularly ones that do not recognize the same sets of attributes.
Explain in normative or non-normative text why the specified behavior is
necessary or desirable for interoperation.
(c) Justify choices made in Appendix B or other non-normative text. The
range of choices must be described, as well as the rationale for the
particular choices.
(d) Correct wording referring to messages to "instances". Clarify who or
what supports what behavior; see related issue on extensibility.
Same as Issue I045: Fixed item #1 and changed last paragraph to the
following:
"This specification defines a number of extensions; compliant services are
NOT REQUIRED to implement those extensions defined in this specification.
However, if a service implements an aspect of the specification, it MUST
comply with the requirements specified (e.g. related "MUST" statements). If
an implementation silently ignore unrecognized attributes where any
attribute is allowed, or silently ignore unrecognized elements where any
element is allowed, should be considered as interoperable implementation."
There are no more SHOULD and MAY in the Conformance section, and no more
"OPTIONAL messages". Item #2, 3 and 4 of this issue should be addressed by
the above changes.
It is proposed to close this issue after the changes.
As in my response to i045, it's OK to close wthis with proposal 2. However, there remain issues on conformance that have not been addressed. After the current round of issues is cleaned up I'll re-examine to ensure that conformance is dealt with in accordance with OASIS procedures.
bill
Discussion. OK to close; will have conformance issue in i053.
Action: i045, i046, i047 Accept Proposal, close after completed and verified.
i037
i045
i047
BSLA - Conformance Issues 1
This issue applies to
BusinessQualityOfService-v1.0-spec-wd04.pdf
BusinessRating-v1.0-spec-wd05.pdf
BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf
Examples are from BQOS. See lines 427-448
This addresses overall issues for conformance that I believe are in all
three specifications. Line numbers from BQOS.
(1) Line 432 - which "table above"?
(2) Many of the conformance clauses reference SHOULD and MAY statements.
It is not clear what MUST be done to conform.
(3) Another issue, Unrecognized Attributes and Extensibility, points out
interoperability issues with the conformance and descriptions as
provided. The choices should be conscious and clearly spelled out and
justified.
(4) The conformance section references "OPTIONAL messages" (line 446 and
elsewhere). What is meant by "message"? And who does or does not
"support" it? This reads as if it were copied from a protocol spec, not
a vocabulary spec.
EERP-SLA
spec
design
William Cox
Szu Chang
N/A
(a) Make terminology consistent; if the inconsistency is correct, state
reason in normative text.
(b) Address interoperability concerns for multiple implementations,
particularly ones that do not recognize the same sets of attributes.
Explain in normative or non-normative text why the specified behavior is
necessary or desirable for interoperation.
(c) Justify choices made in Appendix B or other non-normative text. The
range of choices must be described, as well as the rationale for the
particular choices.
(d) Correct wording referring to messages to "instances". Clarify who or
what supports what behavior; see related issue on extensibility.
Same as Issue I045: Fixed item #1 and changed last paragraph to the
following:
"This specification defines a number of extensions; compliant services are
NOT REQUIRED to implement those extensions defined in this specification.
However, if a service implements an aspect of the specification, it MUST
comply with the requirements specified (e.g. related "MUST" statements). If
an implementation silently ignore unrecognized attributes where any
attribute is allowed, or silently ignore unrecognized elements where any
element is allowed, should be considered as interoperable implementation."
There are no more SHOULD and MAY in the Conformance section, and no more
"OPTIONAL messages". Item #2, 3 and 4 of this issue should be addressed by
the above changes.
It is proposed to close this issue after the changes.
Same response as to i045 and i046:
As in my response to i045 and i-46, it's OK to close wthis with proposal 2.
However, there remain issues on conformance that have not been addressed. After the current round of issues is cleaned up I'll re-examine to ensure that conformance is dealt with in accordance with OASIS procedures.
bill
Discussion. OK to close; will have conformance issue in i053.
Action: i045, i046, i047 Accept Proposal, close after completed and verified.
i038
i045
i046
Use Case Document and additional justification
This issue applies to
BusinessQualityOfService-v1.0-spec-wd04.pdf
BusinessRating-v1.0-spec-wd05.pdf
BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf
On reading all three specifications together, it's not clear what the
relationships are and the intended use cases.
A use case document would help described the intended usage and
approach, and clarify issues I've separately raised.. In particular,
the justification for the mechanisms in the three current
specifications, and a large integrated example, would be very useful.
This issue may be addressed after the current Committee Draft in
progress is completed, but would help the public review be more
effective if addressed before Public Review.
examples
spec
design
William Cox
Szu Chang
N/A
Write a use case and relationships/background document. This could be a
non-normative white paper, or could coordinate with the information from
the non-normative sections (to be written) for the three specifications.
I think that a single use case and relationships document would be best.
Same as Issue I052, it is proposed to change the protocol of this issue to:
Protocol: examples
Artifact: example
Type: design
That is the issue to be addressed in the Example document. No spec changes
are required on this issue for now.
I think this should be addressed by creating a folder for Use Cases and Models as a placeholder, and starting with several of the contributions. Closing this issue is OK, need to open new one for that new document.
bill cox
Category called example. Propose close, but the name of the new document is different in different places. Bill suggests call the new document Use Cases and Model as a working title. Szu: Asks to leave this open.
Action: i048: Keep Open.
BQoS - Schema in Non-Normative Appendix of each Spec for Readability
Schema is not in the specifications. The schema should appear in each
specification in a non-normative appendix, and state that the included
schema is non-normative.
The illustrations (from XMLSpy) should be considered for inclusion as well.
EERP-bQoS
spec
editorial
William Cox
Szu Chang
N/A
Insert as suggested.
Most of OASIS specs do not include the schema list.
The XML Schema for BQoS will be 6 pages long. The illustration (from
XMLSpy) will be too small to read, if put the whole Schema into one page.
Will including schema list into in Non-Normative Appendix of bQoS Spec
really help readability?
We have two alternatives for this issue:
1. Not to include schema into the spec (close with no action)
2. Assign it to editor to include schema into spec
I just finished a detailed review of the Public Review versions of several SCA specs. They all include the schema (without diagrams) in an appendix.
My suggestion is #2, put the schema in the spec (for ease of review).
Similar note on the other issues (i049-i051).
i049, i050, i051: Propose close pending change (proposal 2 #2).
Action: i049, i050, i051: Keep open, append email comment from Bill 3:34pm EDT 24 June 2009.
New working Draft WD06 uploaded at
http://www.oasis-open.org/committees/document.php?document_id=33226 and it
added the XML schema on Line # 479-864.
This issue can be closed.
i050
i051
Rating - Schema in Non-Normative Appendix of each Spec for Readability
Schema is not in the specifications. The schema should appear in each
specification in a non-normative appendix, and state that the included
schema is non-normative.
The illustrations (from XMLSpy) should be considered for inclusion as well.
EERP-Rating
spec
editorial
William Cox
Szu Chang
N/A
Insert as suggested.
Same as Issue I049, most of OASIS specs do not include the schema list.
The XML Schema for Rating will be 7 pages long. The illustration (from
XMLSpy) will be too small to read, if put the whole Schema into one page.
Will including schema list into in Non-Normative Appendix of bQoS Spec
really help readability?
We have two alternatives for this issue:
1. Not to include schema into the spec (close with no action)
2. Assign it to editor to include schema into spec
i049, i050, i051: Propose close pending change (proposal 2 #2).
Action: i049, i050, i051: Keep open, append email comment from Bill 3:34pm EDT 24 June 2009.
New working Draft WD07 uploaded at
www.oasis-open.org/committees/download.php/33230/BusinessRating-v1.0-spec-wd07.pdf and it added the XML schema on Line # 621-1103.
This issue can be closed.
i049
i051
BSLA - Schema in Non-Normative Appendix of each Spec for Readability
Schema is not in the specifications. The schema should appear in each
specification in a non-normative appendix, and state that the included
schema is non-normative.
The illustrations (from XMLSpy) should be considered for inclusion as well.
EERP-SLA
spec
editorial
William Cox
Szu Chang
N/A
Insert as suggested.
Same as Issue I049, most of OASIS specs do not include the schema list.
The XML Schema for Rating will be 7 pages long. The illustration (from
XMLSpy) will be too small to read, if put the whole Schema into one page.
Will including schema list into in Non-Normative Appendix of bQoS Spec
really help readability?
We have two alternatives for this issue:
1. Not to include schema into the spec (close with no action)
2. Assign it to editor to include schema into spec
I'm not sure what you mean by "most of OASIS specs do not include the schema list[ing]." This is, in my experience, universally done even though the separate file starting around 6 months ago was changed to the normative version.
So this is incorrect. The Schema should be included in the specification in an appendix. See, for example, SCA-Assembly.
Comment from a related issue:
I just finished a detailed review of the Public Review versions of several SCA specs. They all include the schema (without diagrams) in an appendix.
My suggestion is #2, put the schema in the spec (for ease of review).
Similar note on the other issues (1049-1051).
bill
i049, i050, i051: Propose close pending change (proposal 2 #2).
Action: i049, i050, i051: Keep open, append email comment from Bill 3:34pm EDT 24 June 2009.
New working Draft WD06 uploaded at
www.oasis-open.org/committees/download.php/33244/BusinessServiceLevelAgreement-v1.0-spec-wd06.pdf
and it added the XML schema on Line # 818-1450.
This issue can be closed.
i049
i050
Use of Business Rating Not Clear
BusinessRating-v1.0-spec-wd05.pdf
The use of BusinessRating is not clear from the specifications. The use
case document (proposed in the Related Issue) would help a great deal.
The bidirectional nature, communicating both a claimed set of
credentials+ratings and (apparently) a validated set of
credentials+ratings is confusing in that it uses the same instance to
communicate two different things.
The two way usage is also confusing in that it follows the "peek/poke"
model of setting parts of a data structure and returning it; if this is
indeed what's being done in the intended use, it should be changed to
something more appropriate for the SOA/web services environment.
examples
example
design
William Cox
Szu Chang
N/A
Refactor to avoid the confusing two way use. Add rationale in a
non-normative appendix to explain and justify the choice made.
It is proposed to change the protocol of this issue to:
Protocol: examples
Artifact: example
Type: design
That is the issue to be addressed in the Example document. No spec chnages
are required on this issue.
The example document is not in our work area at this time.
The explanation is needed for a successful public review, looking forward.
This information could be put in an informative (non-normative) appendix to the spec.
bill cox
Szu: This is the same as i048.
Action i052 Treat as i048.
i048
BQos - Conformance Issues 2
This issue applies to
BusinessQualityOfService-v1.0-spec-wd04.pdf
BusinessRating-v1.0-spec-wd05.pdf
BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf
Consider whether empty instances would allow conforming applications to
exchange information and satisfy the conformance section.
Many of the items are zero or one, or otherwise are not required.
Analysis of the minimal set of exchanged information should be done to
evaluate the quality of the conformance section.
Interoperability testing would reveal these issues, when done.
EERP-bQoS
spec
design
William Cox
Szu Chang
N/A
Conduct analysis as described.
Plan interoperability testing for the future.
Szu: What is this is an empty artifact that conforms? We need a conformance statement.
ACTION Bill will write a separate issue for Interoperability Testing.
Proposal: separate interop testing issue, delete it from these three.
Action: i053, i054, i055: Szu will write minimum requirements. Separate issue needed for Interoperability Testing.
Propose to add the following text to close this issue:
The minimum set of information exchange for bQoS that would allow
conforming applications to exchange information and satisfy the conformance
should at least to have /bqos:BQoS/bqos:BQoSPrice/bqos:Price/bqos:Amount
element, like this:
<?xml version="1.0" encoding="UTF-8"?>
<BQoS xmlns="http://docs.oasis-open.org/soa-eerp/bqos/200903";>
<BQoSPrice>
<Price>
<Amount currencyID="USD">0.0</Amount>
</Price>
</BQoSPrice>
</BQoS>
Interoperability issue has been addressed on issue # I045.
New working Draft WD06 uploaded at
http://www.oasis-open.org/committees/document.php?document_id=33226 and it
added new conformance paragraph on Line # 447-457.
This issue can be closed.
i045
i054
i055
Rating - Conformance Issues 2
This issue applies to
BusinessQualityOfService-v1.0-spec-wd04.pdf
BusinessRating-v1.0-spec-wd05.pdf
BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf
Consider whether empty instances would allow conforming applications to
exchange information and satisfy the conformance section.
Many of the items are zero or one, or otherwise are not required.
Analysis of the minimal set of exchanged information should be done to
evaluate the quality of the conformance section.
Interoperability testing would reveal these issues, when done.
EERP-Rating
spec
design
William Cox
Szu Chang
N/A
Conduct analysis as described.
Plan interoperability testing for the future.
Szu: What is this is an empty artifact that conforms? We need a conformance statement.
ACTION Bill will write a separate issue for Interoperability Testing.
Proposal: separate interop testing issue, delete it from these three.
Action: i053, i054, i055: Szu will write minimum requirements. Separate issue needed for Interoperability Testing.
New working Draft WD07 uploaded at
www.oasis-open.org/committees/download.php/33230/BusinessRating-v1.0-spec-wd07.pdf and it added new conformance paragraph on Line # 575-601.
Basically, there is no required element in the schema, and an empty but
validated XML document is possible, but is not satisfy the conformance on
this spec. The minimum set of information exchange for Business Rating that
would allow conforming applications to exchange information and satisfy the
conformance should have either
/rt:BRating/rt:ListOfRating/rt:Rating/rt:RatingIssuer/rt:IssuerUri element
or
/rt:BRating/rt:Credentials/rt:Credential/rt:CredentialIssuer/rt:IssuerUri
element.
Two examples on the minimum set of information are provided on Line # 579-
589 and 601.
This issue can be closed.
i046
i053
i055
BSLA - Conformance Issues 2
This issue applies to
BusinessQualityOfService-v1.0-spec-wd04.pdf
BusinessRating-v1.0-spec-wd05.pdf
BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf
Consider whether empty instances would allow conforming applications to
exchange information and satisfy the conformance section.
Many of the items are zero or one, or otherwise are not required.
Analysis of the minimal set of exchanged information should be done to
evaluate the quality of the conformance section.
Interoperability testing would reveal these issues, when done.
EERP-SLA
spec
design
William Cox
Szu Chang
N/A
Conduct analysis as described.
Plan interoperability testing for the future.
Szu: What is this is an empty artifact that conforms? We need a conformance statement.
ACTION Bill will write a separate issue for Interoperability Testing.
Proposal: separate interop testing issue, delete it from these three.
Action: i053, i054, i055: Szu will write minimum requirements. Separate issue needed for Interoperability Testing.
New working Draft WD06 uploaded at
www.oasis-open.org/committees/download.php/33244/BusinessServiceLevelAgreement-v1.0-spec-wd06.pdf
and it added new conformance paragraph on Line #
771-797.
This issue can be closed.
i047
i053
i054
BSLA Editorial
Suggested editorial changes has been uploaded as
http://www.oasis-open.org/committees/download.php/33019/BusinessServiceLevelAgreement-v1.0-spec-wd04-wtc.doc
with changes tracked and comments included. Substantive issues are
posted separately.
EERP-SLA
spec
editorial
William Cox
Szu Chang
N/A
Address editorial suggestions
SOA-EERP BusinessServiceLevelAgreement v1.0 spec working draft 05 (WD05)
is uploaded at:
http://www.oasis-open.org/committees/download.php/33073/BusinessServiceLevelAgreement-v1.0-spec-wd05.pdf
Fixed all problem in the issue.
This issue should be closed.
OK to close pending review.
bill cox
Szu: Propose close.
BusinessRating Editorial
Suggested editorial changes has been uploaded as
http://www.oasis-open.org/committees/download.php/33020/BusinessRating-v1.0-spec-wd05-wtc.doc
with changes tracked and comments included. Substantive issues are
posted separately.
EERP-Rating
spec
editorial
William Cox
Szu Chang
N/A
Address editorial suggestions
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 accepted all changes and fixed the comments. See
http://www.oasis-open.org/committees/download.php/33068/BusinessRating-v1.0-spec-wd06-withChanges.doc
It is proposed to close the issue with above changes.
OK to close.
bill cox
Szu proposes closing pending review and re-review by Bill.
Action i057: Close pending review by Bill and TC.
TC to review XML Schema for all three standards
This action item is from issue #i006. The following are latest schema locations:
http://www.oasis-open.org/committees/download.php/32422/EERP-bQoS-wd01.xsd
http://www.oasis-open.org/committees/download.php/32575/EERP-Rating-WD03.xsd
http://www.oasis-open.org/committees/download.php/32500/EERP-SLA-WD02.xsd
New pictures for the schema can be found at the following locations:
.
http://www.oasis-open.org/committees/download.php/32676/EERP-bQoS-WD01.png
http://www.oasis-open.org/committees/download.php/32677/EERP-Rating-WD03.png
http://www.oasis-open.org/committees/download.php/32678/EERP-SLA-WD02.png
.
SOA-EERP TC
Done and closed after June 5 review deadline
TC to review three specifications
This action item is created from June 10's TC meeting. The deadline for submitting comments on review three specifications is Friday, June 19, 2009. The following are latest specifications locations:
BQoS spec WD04 at http://www.oasis-open.org/committees/download.php/32576/BusinessQualityOfService-v1.0-spec-wd04.pdf
Raing Spec WD05 at http://www.oasis-open.org/committees/download.php/32916/BusinessRating-v1.0-spec-wd05.pdf
SLA Spec WD04 at http://www.oasis-open.org/committees/download.php/32837/BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf
SOA-EERP TC members
TC to review three specifications
This action item is created from June 24's TC meeting. Three specifications have been updated for final review. The following are latest specifications locations:
BQoS spec WD06 at http://www.oasis-open.org/committees/download.php/33234/BusinessQualityOfService-v1.0-spec-wd06.pdf
Raing Spec WD07 at http://www.oasis-open.org/committees/download.php/33230/BusinessRating-v1.0-spec-wd07.pdf
SLA Spec WD06 at http://www.oasis-open.org/committees/download.php/33244/BusinessServiceLevelAgreement-v1.0-spec-wd06.pdf
SOA-EERP TC members