[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ebxml-jc] 2/10/2004: Updated Comments on Compatiblity Matrix
See below, thanks. Includes previous and some updated comments. 1. Version annotation: Version annotation is a standard way to annotate a doc, a schema, an implementation, a run-time artifact (e.g. message) with proper version ID. We'll have to decide where to recommend version annotations. It can be a small XML document, just listed in a doc (e.g. Appendix) or inserted in a schema: <specificationId> <fullname>ebXML Messaging Service</fullname> <refname>ebMS</refname> <version>2.0</version> <revision></revision> </specificationId> >>>>mm1: May be important to have an official date attached to the version. Also, per the discussion today 11 Feb, consider a convention for contraction. NOTE: the "refname" is a contraction that is expected to be used in other docs when they refer to this spec. E.g., in the reference section of other docs, for the above example, "[ebMS-2.0]" should be used, in a standard way (reference = <refname> ["-" <version> ["-" <revision> ]]) Note that run-time support should be recommended (e.g. an implementation should be able to "return" such information when queried, e.g. via a Ping.) 2. Compatibility matrix: The matrix should address: (a) implementation compatibility across versions of the same spec: should allow to answer questions like: - will implementation of spec X.0 be compatible with newer X.1? (always? sometimes? never?) - will implementation of latest spec X.1 be compatible with X.0? (always? sometimes? never?) >>>>mm1: You may have to go to more detail here, because, for example, CPPA or CPPA negotiation will expect certain functionality from BPSS, so it may be as specific as an element or function or more generic as per version (spec-to-spec). A more general matrix would also address different specs (not just different by their version): (b) implementation compatibility across specs (different versions, and/or different specs: Here, it is important to first "qualify" the type of relationship between specs: If spec A is "using" spec B: does using mean: - spec A uses spec B as a necessary subset. >>>>mm1: Mandatory because of direct dependency. - spec A uses spec B as an optional extension, e.g. binding. >>>>mm1: Represents an optional function within or across two or more specificiations. - an implementation of spec A is expected to interoperate with an implementation of spec B. For each of these types of relationship, incompatibility between A and B will not have same meaning, implementation-wise. >>>>mm1: Interoperate as is or with transformations, or other changes to provide support? We may have varying degrees of interoperability on core functions. Which brings up at what level or profile is the interoperability or compatibility held? Particularly with your examples above and the references on 'using' below, we may need to address what interoperability really means. Is it against a profile of mandatory core functions? Need to also designate if part of one specification is used in another, if that involves mandatory or optional elements, and whether they are mandatory or optional in the target specification (using specification). Then, a "using" spec (role A above) can list all the "used" specs (role B) with which it is compatible (always, partially, never), for each of the usages above. If these relationships are oriented (here from A to B), then we could require each spec to list all known dependencies with other specs. Something like: <specificationDependencies> <specificationId> <!-- this spec ID --> </specificationId> <relatedSpecification usage="binding" compatibility="full"> <specificationId> <!-- related spec ID --> </specificationId> </relatedSpecification> <relatedSpecification usage="interop" compatibility="partial"> <specificationId> <!-- related spec ID --> </specificationId> </relatedSpecification> ... </specificationDependencies> The matrix would be the union of all these <specificationDependencies> elements, for all specs. --------------- initial requirements (old email from Colleen) (1) We feel there is a need for an OASIS-wide way to implement shema versioning and documentation across OASIS approved schemas. More generally, specifications should include a formal representation of their version number, e.g. using a common XML document format. All this would make it easier to obtain, query, and process the version number of an implementation. >>>>mm1: This has been requested by ebBP users. (2) We also feel there is a need for a common way to represent compatibility links to other specs. While the ebXML Joint Technical Liaison Team is developing an ebXML standards compatibility matrix, a more formal way to code a compatibility matrix (for integration as well as interoperability) is required across OASIS, ideally a model that could be processed by a tool and well understood across specifications. ------------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]