Re: [ebxml-bp] ebBP 4/1/2005: Comment re: Specification Version(wd10-schema 2/22)

["Monica J. Martin" <Monica.Martin@Sun.COM>]

mm2: Thanks Kenji for the prompt and important comment. See inline.

> Nagahashi: Hi,
> I suppose it is confusing to explain both BPSS tech specification 
> versioning and BPSS instance versioning as "versioning support", since 
> only versioning mechanism users can really utilize is 
> "instanceVersion."  Value of namespace and "specificationVersion" are 
> fixed as long as users use particular version of BPSS tech 
> specification and this could be totally hidden when users use BPSS 
> authoring tools. From uses' perspective, this is not a "versioning 
> mechanism," I believe.

mm2: It is actually a reference if you look at it broadly so I 
understand your distinction. The suggested text below for the technical 
specification. I don't believe we need to change the schema annotations 
however unless someone has any suggested changes.

> Following is my proposal for Section 4.6.4:
> -----
> 4.6.4 Versioning
>
> The ebBP technical specification supports versioning of ebBP instance 
> with instanceVersion attribute of ProcessSpecification element. 
> instanceVersion attribute MAY be used to distinguish different 
> revisions of a business process. ebBP technical specification does not 
> define specific format for the value of instanceVersion attribute. 
> Authors MAY choose arbitrary text of their convenience. [Is this 
> right? YES]

mm2: I'd like to retain two points: 1) instanceVersion: That it is 
typically the industry known version of their ebBP instance, and 2) 
versioning by schema namespace: I'd like to re-integrate this text and 
the possibility of minor variant versions within a namespace handled by 
different URLs for schema location.

> instanceVersion attribute should not be confused with 
> specificationVersion attribute, which is the version identifier of 
> ebBP technical specification that ebBP instance comply with. 
> specificationVersion MUST always have value "2.0", if specified, for 
> ebBP instances that conform to this technical specification.
>
> Two process models with different specification versions could in 
> principle have the same instance version.
>
> The attribute uuid SHALL NOT ...
> -----
> I dropped "with either different schemas or even" from line 732, because
> different schema should always based on different version of
> specification, I thought. 

mm2: I don't see an issue with this change, Kenji. I've proposed some 
compromised text below. We can discuss in today's call. Thanks.

>> Technical specification
>> Section 4.6.4 Versioning
>>
>> Change from:
>> The ebBP technical specification supports three types of versioning:
>>
>> ·         Versioning of schema by namespace (where minor variant 
>> versions within a namespace are handled by different URLs for schema 
>> location). The namespace URL always contains the most up-to-date schema.
>>
>> ·         Versioning by specification
>>
>> Versioning of the artifact instances such as to track differences or 
>> group similarities........
>>
>> Change to:
>
[updated] The ebBP technical specification supports versioning of an 
ebBP instance with instanceVersion attribute of ProcessSpecification 
element. The instanceVersion attribute MAY be used to distinguish 
different revisions of a business process. The ebBP technical 
specification does not define specific format for the value of 
instanceVersion attribute. Authors, such as those within an industry, 
MAY choose arbitrary text of their convenience to recognize their 
assigned instanceVersion.

The instanceVersion attribute should not be confused with 
specificationVersion attribute, which is the version identifier of ebBP 
technical specification of which that ebBP instance MUST comply. 
specificationVersion MUST always have value "2.0", if specified, for 
ebBP instances that conform to this technical specification.  Two 
process models with different specification versions could in principle 
have the same instance version.

The ebBP schema version MUST be defined by namespace (where minor 
variant versions within a namespace are handled by different URLs for 
schema    location). The namespace URL always contains the most 
up-to-date schema.

The attribute uuid SHALL NOT ... [end updated]

>> [no change] BPSS schema
>> Change from:
>> - <#> <xsd:element name="*ProcessSpecification*">
>> - <#> <xsd:annotation>
>>  <xsd:documentation>Root element of a process specification document 
>> that has a globally unique identity. The process specification 
>> element can specify the version of the technical specification used 
>> and the BPSS instance version related to the target BPSS 
>> (schema).</xsd:documentation>
>>  </xsd:annotation>
>> - <#> <xsd:complexType>
>> - <#> <xsd:complexContent>
>> - <#> <xsd:extension base="*ProcessSpecificationType*">
>> - <#> <xsd:attribute name="*specificationVersion*" 
>> type="*xsd:NMTOKEN*" use="*optional*">
>> - <#> <xsd:annotation>
>>  <xsd:documentation>Is the version of the Process Specification. 
>> Note: This attribute was added in v2.0.</xsd:documentation>
>>  </xsd:annotation>..........................
>> </xsd:complexType>..........................
>> </xsd:element>
>>
>> Change from:
>> - <#> <xsd:element name="*ProcessSpecification*">
>> - <#> <xsd:annotation>
>>  <xsd:documentation>Root element of a process specification document 
>> that has a globally unique identity. The process specification 
>> element can specify the version of the technical specification used 
>> and the BPSS instance version related to the target BPSS 
>> (schema).</xsd:documentation>
>>  </xsd:annotation>
>> - <#> <xsd:complexType>
>> - <#> <xsd:complexContent>
>> - <#> <xsd:extension base="*ProcessSpecificationType*">
>> - <#> <xsd:attribute name="*specificationVersion*" 
>> type="*xsd:NMTOKEN*" use="*optional*">
>> - <#> <xsd:annotation>
>>  <xsd:documentation>Is the version of the Process Specification. Also 
>> reference ProcessSpecificationType. Note: This attribute was added in 
>> v2.0.</xsd:documentation>
>>  </xsd:annotation>..........................
>> </xsd:complexType>..........................
>> </xsd:element>
>
> =========================================================================================================== 
>