OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-calendar-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Streams specification comments


Dear list,

 

I worked on the Streams spec. Find my comments below.

Line numbers are based on the Pdf version: streams-v1.0-csprd02.pdf

 

Typos and editorial issues:

Line 21: “as a means to”

Line 79: “STREAMS” in caps – Shouldn’t it be “Streams” according to the naming and editing conventions ?

 

Line 114 (table 2-1):

-          In Artifact description line 1: “…in an Component”

-          In Availability description line 2: “…of which expresses a set of…”

-          In Component description line 6: “A Sequence is a set of …”

-          In Interval description line 1: “The Interval is a single discrete segment.”. Isn’t “The Interval is a single discrete segment of time.” better?

-          In Component description line 6: “A Sequence is a set of …”

-          In Link description line 1: “.. within the same Calendar”

 

Line 118: The second part of the first sentence is missing a word, a verb ? “ie, it is a set if Intervals that can be using a Sequence of Intervals” ?

Line 131 + on the last row of the following table: How does the asterisk “*” should be interpreted ?

 

Line 143 (table 2-2):

-          In Inheritance description line 1: “…which information in a Sequence…”

 

Line 149: “…which in turn bequeaths its information…”

Line 164: Double dots.

 

Line 156 (table 3-1):

-          According to the naming/editing convention, capitalization seems incorrect: “UID” instead of “Uid” (4 times) – UID is a well-known acronym, all in caps as for ‘SOAP’.

-          Last line of the UID description: “..artifacts acting as…”

 

Line 167: “…the Stream Base acts as a Gluon…”

Line 168: “entire Stream”

Line 170: “…within each Interval”

Line 175: “from the Stream Base” and “Lineage” (remove italic and add a capital L)

Line 178: “For a Stream”

Line 179: “to order the Intervals…”

Line 180: “UID” instead of “Uid”.

Line 185: “Intervals”, “UID”, “Interval”

Line 186: “…each Intervals…”

Line 195: “Interval” and “Stream”

Line 207: “Interval”

Line 221: The sentence does not read easily due to the part between comas. As a non-native speaker, I do not have any advice ;-)

Line 225: “Sequence”.

Line 235: “… be the same”.

Line 239: Something is missing in “…the and a unique ID…”

Line 246: “Artifact” and “Payload”.

Line 250: “Interval”

Line 251: “Payload”

Line 252: “Payload” and “Streams”

Line 253: “Streams”

Line 257: “Intervals”.

Line 259: “Report”

Line 261: “Payloads”.

Line 262: “Payload”.

Line 270: “are a means

Line 276: “Artifact” (twice)

Line 289, 290 & 293: “Sequence Number”

Line 292: “Intervals”

Line 302: “Designated Interval”, and it is probably worth adding a definition of Designated Interval in table 3-1 ?

Line 343: “Interval”

Line 344: “Sequence”

 

I have seen a bulk of capitalization issues for keywords such as SHALL, MUST, CAN, MAY… Here is my list, I MAY have missed some others ;-)

Line 164, table 3-1 (MUST once, MAY once), 257, 259, 285, 289, 300, 333, 335, 338, 344

 

Technical comments

Line 166 Table 3-1: The Stream Base has a very basic definition (is an abstract element…), and most of the useful information (for understanding I mean) is a “MAY”. Defining something with MAYs is probably not the best for interop at large.

 

Line 172 Figure 3-1

The group of first 3 elements is not a Gluon as the legend says, it is “Gluon-like” or “Equivalent to a Gluon”.

Same remark for the last element: It is not a Sequence as the legend says, it is “Sequence-like”.

 

Line 198: “by either pre-pending or by appending” The section 4.2.1 says “appending” only. Only one rule shall be allowed.

Line 186: I expect a copy/paste mistake more than a technical issue:

-          The text says “Stream UIDs must only be unique within the Stream, each Interval is uniquely identified by a Stream UID”.

-          Shouldn’t this be “Interval UIDs must only be unique within the Stream, each Interval is uniquely identified in the scope of the Stream it belongs to (the Stream being itself identified with its UID)”.

-          Or something similar ?

 

About the section 3.4:

-          If the aim of the Stream spec is to define a profile for Sequence/Partition/Interval, then this should be stated more clearly, and a way is to change the title of 3.4 to something like: “Stream – A specific profile definition for Sequences and Intervals” or alike

-          Line 205: “Streams describe a particular form of Partitions” ?

-          Starting line 213 and in section 3.5, terms coming from EI are used, they probably need a definition reminder as for WS-Calendar terms in 2.1: Sequence Number, Event, Signals, Report.

-          Line 214/215: “The effect of this is that Stream Intervals are ordered as a Partition in order of increasing UID.”
This sentence assumes there is an ordered relation for UIDs, which can be true for a particular implementation, but is not the case in general as UIDs are derived from a string datatype. This kind of assumption can not be left as is without a conformance statement making mandatory the usage of a particular datatype / order relation for the UIDs. Unless implementations will never interop (even using the same datatype let say numbers hold in a string datatype: One could sort alpha, the other could cast to Int then sort numerically or vice-versa).

-          Line 297 suffers from the same weakness.

 

About the section 3.5:

-          Line 250: “Unless each Interval includes a full payload…”: One never know if the full payload is defined in a particular Interval or not. My view as a potential implementer is that this rule shall be expressed as a priority/precedence rule: “Interval payload data have precedence over Sequence/Stream payload, and Gluon payload has precedence over Sequence/Stream payload”.

 

About the section 3.6:

-          Title for 3.6: Same spirit as my comment on the title for section 3.4. Are we talking about “Other elements in Stream Payloads” or are we talking about “Stream Payload extension” ?

-          And Line 262 should be the first sentence of the section 3.6: A statement, and then examples (line 257 to 261 are examples of Payload extensions), not the contrary.

 

About the section 4 – Conformance

I do not know the OASIS rules deeply, but the section 4 is mostly a copy/paste of the body of the spec. Does duplicating information a form of conformance enforcement ?

We are missing the basic there, clear and simple text including:

-          The set of concepts/components/parameters/properties one need to support to claim conformance.

o   “In addition to conforming to WS-Calendar PIM, implementations claiming conformance with this specification SHALL support: Inheritance within Streams according to section xx, Support Stream Payload Base according to section xx…”

o   “The following MAY not be supported and still allow claiming conformance: ….
(I let the group state what SHALL be supported, what MAY be supported)

-          The optionalities:

o   An implementation claiming conformance to… SHALL declare:

§  The inheritance rules it applies (while processing received data, while processing data for transmission)

§  The UIDs datatype, cast, ordering rules  for Intervals within a Stream + Construction of Ids as in 4.3.2

§  Lineage

§ 

 

This would avoid repetition, and clarify what are MUST and what are MAY.

 

General comment:

From a standard prospective, I do not know the full story around Streams in the EI context, and it is probably too late, but:

-          Why not making Sequence a type of Component ?

-          Why not enhancing the notion of Partition/Sequence to cope with the need for Streams ?

 

My understanding is that Streams are just a particular kind of Sequence (Partition), a new animal with particular rules of inheritance to minimize the amount of repeated data (by inventing the Stream Payload Base). Why not doing that with animals we already domesticated: A Gluon Payload Base or Sequence Payload Base?

 

I do not feel comfortable with such overlapping concepts and specifications.

 

Regards.

 

Benoît LEPEUPLE

Product Manager

ARC Informatique

 

2 avenue de la cristallerie - 92310  SEVRES  - FRANCE

Tel: +33 1 41 14 36 00 - Mobile: +33 6 87 80 20 43 

Email : b.lepeuple@arcinfo.com

 

www.pcvuesolutions.com

 

Signature

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]