[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 4/7/2005: Comment re:uuid (relates to Versioning comments)[wd11-schema 4/1]
In Tuesday's call, we sought to clarify even more the importance of uuid while enabling the community to use the mechanisms in place for v2.0 for instance, specification and schema versioning. Discussion summary and decision: * Typically different business process definitions have different uuids. Each definition should have its own uuid. * If uuids are the same for different definitions, they use the same version (where used: schema, technical specification and instance). Only if the uuids are the same, is the version the same. Conversely, those definitions could have different uuids and the same version (as referenced above) but in different repositories. The uuid may be used in implementation but it cannot be used to guarantee that things are the same. * Recognize the value of uuid for direct addressing for straightforward implementation. * Decision - add this more detailed text to the spec and schema. =========================================================================================================== Tech spec Section 4.6.4 Versioning Change from: The attribute uuid SHALL NOT be used for the purpose of versioning, so that even a change introduced by AttributeSubstitution (to business documents’ schemas, for example), would be marked by a new uuid. So while the same instance version could appear in two documents with different schema namespaces, for example, they each would have different uuids. Change to: [add after this paragraph] The attribute uuid SHALL NOT be used for the purpose of versioning, so that even a change introduced by AttributeSubstitution (to business documents’ schemas, for example), would be marked by a new uuid. So while the same instance version could appear in two documents with different schema namespaces, for example, they each would have different uuids. [add] The uuid is not a guarantee that the version is the same. Taking two examples, one that is more predictable than the another. In the first case, the uuid is the same for different business process definitions. Therefore, they are the same version (ebBP schema and, where used, instance and specification version). However, in a second case: If the definitions exist in different repositories, each could have a different uuid. Regardless, the uuid is valuable for use in implementation. [end-add] Schema [on ProcessSpecificationType] Change from: - <#> <xsd:attribute name="*uuid*" type="*xsd:string*" use="*required*"> - <#> <xsd:annotation> <xsd:documentation>Defines a string identification mechanism for a Process Specificiation. The uuid SHALL NOT be used for the purpose of versioning, so that even a change introduced by AttributeSubstitution (to business documents’ schemas, for example), would be marked by a new uuid. So while the same instance version could appear in two documents with different schema namespaces, for example, they each would have different uuids.</xsd:documentation> </xsd:annotation> Change to: - <#> <xsd:attribute name="*uuid*" type="*xsd:string*" use="*required*"> - <#> <xsd:annotation> <xsd:documentation>Defines a string identification mechanism for a Process Specificiation. The uuid SHALL NOT be used for the purpose of versioning, so that even a change introduced by AttributeSubstitution (to business documents’ schemas, for example), would be marked by a new uuid. So while the same instance version could appear in two documents with different schema namespaces, for example, they each would have different uuids. The uuid is not a guarantee that the version is the same. The uuid could be the same for different business process definitions. Therefore, they are the same version (ebBP schema and where used instance and specification version). However, if the definitions exist in different repositories, each could have a different uuid. Regardless, the uuid is valuable for use in implementation. </xsd:documentation> </xsd:annotation> ===========================================================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]