Re: [ubl-comment] Ammendment Re: Suggestion for a basis for subsetprofile conformance clauses

[Stephen D Green <stephengreenubl@gmail.com>]

Thanks

�

I'd just add a couple more benefits in having a published

subset.

�

Besides providing for a conformance profile, a published

subset, I suggest, can provide a demarcation measure

such that trading parties can document their system

capabilities in comparison to the subset, using the subset

as a reference point. The sending system can be described

in relation to the subset that there are X and� Y BIEs which

it cannot send and also that there is a BIE Z which it

cannot NOT send (such as one required by law for its

locality or industry). Likewise receiving systems can publish

documentation to say that they cannot receive Z and MUST

receive Y in the subset but otherwise comply with the subset.

�

Similarly other subsets and conformance profiles can be

published as a diff from the existing subset profile - subset

XYZ is as subset ABC except that it adds a requirement

to include BIE X in all invoice documents, etc. Even BII and

OIO UBL could be documented�with regard to which BIEs

they add to the�basic subset ABC and which they remove.

This would perhaps�help system architects more quickly

analyse subsets and systems when they are all documented

as diffs from a common basic published / 'standard'�subset.�
It might be easier than each subset being compared instead

to the UBL standard documents in their entirety. They might,

for instance have it documented that their laws require them

to use the core subset ABC plus BIE X. If they see subset

XYZ�is the core plus X and Z�and minus�Y they only need

find out whether Y is essential before OK-ing subset XYZ.�

----

Stephen D Green

On 2 August 2011 14:48, Jon Bosak <bosak@pinax.com> wrote:

Thanks, Stephen. �I'm going to arrange a discussion of this in an
upcoming TC call.

Jon

Stephen D Green wrote:

Third time lucky... �I'm still getting to grips with this. Sorry
for my slowness to understand it all.
�Now I think some more I reckon there can be two main
conformance levels/types (or three if you add one combining
the other two) for a given subset.
�conformance type 1: (as I wrote previously)
the sender
can send every BIE in a conformance (sub)set of the subset
the receiver
can receive a document with every BIE in the subset
�but then there is the other type, to which I think you allude
�conformance type 1: (as I wrote previously)
the sender (has a mode of operation in which it ...)
can send a document with no BIEs which are not in a conformance (sub)set of the subset
the receiver
can receive a document with every BIE in the subset
and
can fail to receive (reject) any document with BIEs which are not in a conformance (sub)set of the subset
�The second can make the schema central to conformance tests.
�The second is more valuable to receiving systems but may be less testable (not every doc can be tested).
�I guess both have pros and cons.
�The first is to my thinking more akin with Postel's law putting less onus on senders. Both are valid though.
�Best regards
----
Stephen D Green

On 2 August 2011 09:27, Stephen D Green <stephengreenubl@gmail.com <mailto:stephengreenubl@gmail.com>> wrote:

� �Hi Jon
� � � � Reading through your question again, I may not have answered it.
� � � � Are you asking for elaboration on the actual 'predicates' in the
� �test assertions?
� �In other words, the actual logic of the suggested profile spec
� �statements?
� � � � I guess they are aimed more at a sending system than at the document
� �sent.
� �That is the key to understanding how they differ from (subset)
� �schema validity.
� �The schema constrains the document but these statements (and test
� �assertions
� �based on the statements) go ufrther by stating that a sending system
� �MUST
� �be able to send X, Y and Z in a document. That is not to say a
� �document MUST
� �contain X, Y and Z. If Z is mandatory in the schema, one document
� �might contain � � Y and Z and another document might contain X and Z. If the system
� �can send
� �a document with X and Z and it can send a document with Y and Z
� �it conforms.
� �It it cannot send Y and Z then it doesn't conform to this profile
� �(even though its
� �documents might all be valid according to the schema). If it sends
� �documents
� �with X and Y but not Z then there will be a failed test but this
� �cannot always be
� �relied on for conformance because tests cannot prove it will never
� �send such
� �a document. This is the weakness of using a schema and validity of
� �documents
� �alone as a conformance test - you can never test all documents. My
� �suggestion
� �is to apply conformance testing such that the sending system has to
� �prove that
� �it can send some set of documents which between them contain all
� �BIEs in a
� �set. (It is a little more complex in that the subset itself may be a
� �superset of all
� �the BIEs in the set required for conformance. A conforming system
� �can still
� �conform, according to a given profile spec, even if it never, say,
� �implements
� �each and every, Signature BIE, provided these BIEs are not part of
� �the set
� �which determines conformance. The Signature BIEs might all be there
� �in the
� �subset schema though.) � � ----
� �Stephen D Green



� �On 1 August 2011 17:49, Jon Bosak <bosak@pinax.com

� �<mailto:bosak@pinax.com>> wrote:

� � � �Hello Stephen,

� � � �I like the idea of a basic subset (always have), and I'm happy
� � � �to have
� � � �the benefit of your work on this.

� � � �A question about the test assertion approach, however. �I'm having
� � � �trouble seeing how these assertions go beyond just saying "you
� � � �have to
� � � �validate against the subset schema, and in addition, these
� � � �optional UBL
� � � �elements are mandatory." �(In which case, of course, you could just
� � � �modify the subset schema to that effect.) �Could you help me
� � � �understand
� � � �this?

� � � �Jon

� � � �Stephen D Green wrote:

� � � � � �I would refine the previous comment to say that the previous
� � � � � �receiving system
� � � � � �conformance clause might not have been fully testable (since
� � � � � �not every possible
� � � � � �document received will be tested). I could refine this to
� � � � � �say that a receivng system
� � � � � �MUST be able to receive a document which contains every
� � � � � �element in the subset
� � � � � �and every multiple cardinality element twice or more times
� � � � � �in the document.
� � � � � � I would suggest that continuing along the lines of a
� � � � � �conformance test centric subset profile there might be
� � � � � �consideration of test assertions for such a
� � � � � �profile, again considering testability of the assertions and
� � � � � �the normative
� � � � � �statements from which they are derived.
� � � � � � Here is an example of a test assertion set for, say, a
� � � � � �conformance clause relating to
� � � � � �the invoice document type (there might be a clause for each
� � � � � �type to allow
� � � � � �implementations to implement just one or more document types
� � � � � �and still
� � � � � �be conformant).
� � � � � � It is based on an example profile which somehow lists every
� � � � � �element (ignoring
� � � � � �attributes for conformance requirements except insofar as
� � � � � �they are ever mandatory
� � � � � �for the UBL standard schema validity for that document type)
� � � � � � e.g.
� � � � � � Where the profile for the subsets contains statements like
� � � � � �this:
� � � � � �...
� � � � � �Statement INV004: A subset sending system which can send a
� � � � � �subset invoice MUST be able to send a document valid
� � � � � �according to the OASIS standard UBL 2.1 Invoice schema and
� � � � � �containing element /in:Invoice/cbc:ID
� � � � � � Statement INV005: A subset sending system which can send a
� � � � � �subset invoice MUST be able to send a document valid
� � � � � �according to the OASIS standard UBL 2.1 Invoice schema and
� � � � � �containing element /in:Invoice/cbc:CopyIndicator
� � � � � �... one such statement for each element in the subset or a
� � � � � �table to the same effect or some other
� � � � � �blanket statement to this effect including reference to an
� � � � � �overall schema for the subset
� � � � � �...
� � � � � � The conformance clause for subset invoice sending systems
� � � � � �would require conformance to
� � � � � �all these statements. Another clause for receiving systems
� � � � � �might require conformance to
� � � � � �a statement that receiving systes receiving a subset invoice
� � � � � �be able to receive one with all
� � � � � �elements in the subset (including multiple occurences where
� � � � � �the schema includes multiple
� � � � � �occurences).
� � � � � � Test assertions could be presented in the form of markup
� � � � � �like this
� � � � � �-- here using OASIS (in progress) Test Assertion Markup
� � � � � �Language:


� � � � � �<!-- one set of normative statements and corresponding test
� � � � � �assertions for every document type in the subset and for
� � � � � �each of these sets one corresponding conformance clause for
� � � � � �sending systems (for that document type) and one for
� � � � � �recieving systems (for that document type) -->
� � � � � �<testAssertionSet
� � � � � �xmlns="http://docs.oasis-open.__org/ns/tag/taml-201002/
� � � � � �<http://docs.oasis-open.org/ns/tag/taml-201002/>"
� � � � � �setid="ubl-subset.example.ta-__set.1" setname="Invoice Subset">
� � � � � �<common>
� � � � � �...
� � � � � �<!-- need some bindings for prefixes used in the XPath
� � � � � �expressions -->
� � � � � �</common>
� � � � � �...
� � � � � �<testAssertion id="ubl-invoice-subset.__example.ta.s4">
� � � � � �<!-- the actual nomative source might be a table or might
� � � � � �rely on a schema to list all elements in the subset
� � � � � �(attributes too but these might be optional) -->
� � � � � �<normativeSource><__derivedSourceItem documentId="..."
� � � � � �resourceProvenanceId="..." uri="...">A subset sending system
� � � � � �which can send a subset invoice MUST be able to send a
� � � � � �document valid according to the OASIS standard UBL 2.1
� � � � � �Invoice schema and containing element
� � � � � �/in:Invoice/cbc:ID</__derivedSourceItem></__normativeSource>
� � � � � �<target>subset sending system</target>
� � � � � �<prerequisite>can send a subset document valid according to
� � � � � �the OASIS standard UBL 2.1 Invoice schema</prerequisite>
� � � � � �<predicate>can send a document valid according to the OASIS
� � � � � �standard UBL 2.1 Invoice schema and containing element
� � � � � �/in:Invoice/cbc:ID</predicate>
� � � � � �<prescription level="mandatory"/>
� � � � � �</testAssertion>
� � � � � �<testAssertion id="ubl-invoice-subset.__example.ta.s5">
� � � � � �<normativeSource><__derivedSourceItem documentId="..."
� � � � � �resourceProvenanceId="..."
� � � � � �uri="...">...</__derivedSourceItem></__normativeSource>
� � � � � �<target>subset sending system</target>
� � � � � �<prerequisite>can send a subset document valid according to
� � � � � �the OASIS standard UBL 2.1 Invoice schema</prerequisite>
� � � � � �<predicate>can send a document valid according to the OASIS
� � � � � �standard UBL 2.1 Invoice schema and containing element
� � � � � �/in:Invoice/cbc:CopyIndicator<__/predicate>
� � � � � �<prescription level="mandatory"/>
� � � � � �</testAssertion>
� � � � � �<testAssertion id="ubl-invoice-subset.__example.ta.s6">
� � � � � �<normativeSource><__derivedSourceItem documentId="..."
� � � � � �resourceProvenanceId="..."
� � � � � �uri="...">...</__derivedSourceItem></__normativeSource>
� � � � � �<target>subset sending system</target>
� � � � � �<prerequisite>can send a subset document valid according to
� � � � � �the OASIS standard UBL 2.1 Invoice schema</prerequisite>
� � � � � �<predicate>can send a document valid according to the OASIS
� � � � � �standard UBL 2.1 Invoice schema and containing element
� � � � � �/in:Invoice/cbc:UUID</__predicate>
� � � � � �<prescription level="mandatory"/>
� � � � � �</testAssertion>

� � � � � �<!-- one normative statement and corresponding test
� � � � � �assertion for every element in the subset for that document
� � � � � �type -->
� � � � � �...

� � � � � �<testAssertion id="ubl-invoice-subset.__example.ta.r1">
� � � � � �<normativeSource><__derivedSourceItem documentId="..."
� � � � � �resourceProvenanceId="..."
� � � � � �uri="...">...</__derivedSourceItem></__normativeSource>
� � � � � �<target>subset receiving system</target>
� � � � � �<prerequisite>can receive a subset document valid according
� � � � � �to the OASIS standard UBL 2.1 Invoice schema</prerequisite>
� � � � � �<predicate>can receive a document valid according to the
� � � � � �OASIS standard UBL 2.1 Invoice schema and containing every
� � � � � �single-occurence element in that subset once and
� � � � � �multiple-occurence element in that document twice or
� � � � � �more</predicate>
� � � � � �<prescription level="mandatory"/>
� � � � � �</testAssertion>
� � � � � �...

� � � � � �</testAssertionSet>

� � � � � � Best regards
� � � � � � ----
� � � � � �Stephen D Green



� � � � � �On 30 July 2011 18:40, Stephen D Green
� � � � � �<stephengreenubl@gmail.com
� � � � � �<mailto:stephengreenubl@gmail.com>

� � � � � �<mailto:stephengreenubl@gmail.__com

� � � � � �<mailto:stephengreenubl@gmail.com>>> wrote:

� � � � � � � Suggestion for a basis for subset profile conformance clauses
� � � � � � � � � � � � In the UBL 1.0 Small Business Subset were
� � � � � �clauses which
� � � � � � � I found later to be very difficult to test precisely and this
� � � � � � � might make conformance testing and conformance claims
� � � � � � � problematic. The introduction of conformance clauses in
� � � � � � � recent standard specifications is to aid interoperability and
� � � � � � � promote adoption through the clarification of what it means
� � � � � � � for an implementation to conform to a standard specification.
� � � � � � � � � �To promote adoption of subsets for the OASIS Universal
� � � � � � � Business Language it is important to include a conformance
� � � � � � � clause of set of clauses and I would suggest that a subset
� � � � � � � conformance clause should target more than just the UBL
� � � � � � � documents (Invoice, Order, etc) themselves but also there
� � � � � � � should be a conformance clause for a sending system, one
� � � � � � � for a receiving system instead of or in addition to the
� � � � � �clause
� � � � � � � for conformance of the documents themselves. I would like
� � � � � � � to suggest as a basis for the clause for the conformance
� � � � � � � target of sending system conformance to a set of statements
� � � � � � � which amount to the sending system being able to send a
� � � � � � � certain set of BIEs in a given document, as defined by the
� � � � � � � subset schema for that document. I would suggest that a
� � � � � � � basis for a clause for the target of a receiving system
� � � � � �would � � be a conformance clause requiring that the system MUST
� � � � � � � NOT reject a document merely because of the presence in
� � � � � � � it of any of the BIEs as defined by the subset schema (or
� � � � � � � list of BIEs, e.g. given as a set of XPath expressions).
� � � � � � � � � �As a simplistic example, if a subset contains BIEs
� � � � � �X,Y,Z of
� � � � � � � which Y and Z are mandatory and X is optional, there could
� � � � � � � be a set of specification requirements to the effect that the
� � � � � � � sender system MUST be able to send all BIEs X, Y and Z
� � � � � � � in sending that particular document (even though only Y
� � � � � � � and Z are mandatory in any given document of that type).
� � � � � � � A conformance clause for the target of the sending system
� � � � � � � would mandate these particular statements as necessary
� � � � � � � for the conformance of that system. A set of statements that
� � � � � � � target the receiving system would require that the system
� � � � � � � MUST NOT reject a document of that type merely because
� � � � � � � it contains BIE X or Y or Z. A conformance clause for the
� � � � � � � receiving system would make the statements mandatory
� � � � � � � for conformance by such a system. There would be a set of
� � � � � � � �statements for each conformance target that the documents
� � � � � � � of that type MUST contain BIEs Y and Z because these are
� � � � � � � mandatory.
� � � � � � � � � �Such conformance clauses and this focus on
� � � � � �testability may
� � � � � � � help to promote adoption of any given subset and contribute
� � � � � � � to successful adoption and interoperable implementations.
� � � � � � � � � � � � Best regards
� � � � � � � � � �----
� � � � � � � Stephen D Green