[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 2/22/2005: Section 4.4.2 and Section 4.6.3.2 Encrypted/Binary Data
As discussed in today's TC call, we should consider the level of abstraction that ebBP operates, when considering this question that actually touches on the wire format (which is outside of our scope). Section 4.4.2 No changes requested. Section 4.6.3.2 (where specification is defined) Change from: A specification element provides the type, location, target namespace and identifier of the specified elements. For example, if the business document uses different namespaces, each of which has a schema, any or all MAY be specified using a sequence of specification elements. For example, the retail industry uses a logical business document and requires different parts be identifiable (i.e. multiple references to the content structure exist which MAY include multiple schemas and/or namespaces). Change to: A specification element provides the type, location, target namespace and identifier of the specified elements. For example, if the logical business document uses different namespaces, each of which has a schema, any or all MAY be specified using a sequence of specification elements. For example, the retail industry uses a logical business document and requires different parts be identifiable (i.e. multiple references to the content structure exist which MAY include multiple schemas and/or namespaces). It is relevant to note that the ebXML BPSS focuses on the logical business document not a wire format. Therefore, in maintaining that abstraction, focuses on providing a DocumentSpecificationType that allows a pointer to more information about that specification. This capability also may assist in providing a hint to a system, while also allowing an application, middleware or a service, to bound what it may be capable of processing.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]