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

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

If it helps, I thought to call conformance type 1 the 'benchmark'
(it is a sender capabilities minimum requirement for conformance)
and the conformance type 2 the 'ceiling' (it is where the sender

is bound to not send anything which does not conform to a subset
schema (and the subset schema sets the outer bounds of what
can be sent) - in a certain mode (outside of that mode the profile
does not apply but other profiles might such as overall standard

conformance).

I would suggest that these two conformance types - ceiling and
benchmark - could be defined using separate subsets, all within 
one 'subset conformance profile'. One part of the conformance

clause could define the benchmark using one subset (e.g. the
subset I labelled just 'subset' and of the order of UBL 1.0 SBS)
and another part of the clause could define the ceiling using
a separate larger subset (obviously it has to be the same 'size'

or larger, such as the subset schema set I called 'subsetPlus').

It would make sense to me if the proposed basic subset for
UBL 2.1 did in fact use a benchmark like my 'subset' sent
previously but defined using XPaths (e.g. in both a table in

the spec and perhaps test assertions based on that table)
and it would make sense if it also included a ceiling like
the subsetPlus schema set I sent where all BIEs in well
known existing subsets such as OIO were included along

with the previous benchmark subset BIEs too. Then a 
conforming target implementation would ensure it can 
send all BIEs in the 'inner', 'benchmark' and also ensure it
has a mode of use (perhaps indicated using one of the 

purpose made UBL IDs like ProfileID or CustomisationID)
where it does not send anything not valid according to the
ceiling. The ceiling conformance could be tested with a
ceiling subset and there might be a need for test cases 

(perhaps using the XPaths) to test that every possible
benchmark BIE *CAN* be included in any document.

----

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