[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-comment] Ammendment Re: Suggestion for a basis for subsetprofile conformance clauses
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 > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]