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 <
> <mailto:>> 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 <
> <mailto:>> 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
> <
> <mailto:>
> <mailto:stephengreenubl@gmail.__com
> <mailto:>>> 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
>
>
>
>
