ebBP 2/22/2005: Section 4.4.2 and Section 4.6.3.2 Encrypted/Binary Data

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

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.