[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
Stephen, Another excellent topic for us to explore. I think you're giving us some interesting talk time in Kars next month! Jon Stephen D Green wrote: > I'd even like to suggest revisiting the idea I put forward in the early > discussions regarding subsets (leading up to the UBL 1.0 SBS) > that there could be some kind of handshake before sending a > document to ascertain the receiver's subset preferences / capabilities. > > I suggest maybe there could be scope still for the UBL TC itself > to provide message types for a query and response to get from a > potential document receiver a list of their acceptable 'profiles' (I > mean this word in the sense of subsets as in previous comments). > Maybe all that is needed is a pair of document types (not business > documents perhaps but perhaps akin to the ApplicationResponse) > - UBLProfileListRequest and UBLProfileListResponse, say (better > names than these though, I guess). Maybe it is ProfileIDs which > are returned or maybe CustomisatioIDs, I don't know. A list and > maybe a preferred one too could be returned. The document type > would need to be in the request. If both request and response were > given IDs then maybe a pair of BIEs to quote these in subsequent > documents too would be valuable (for auditing purposes, maybe legal). > > I do understand this would put some pressure though on implementations > of UBL to implement this kind of open processing so maybe it is for > BDX TC or the like, but to have something like this as part of UBL > itself seems very valuable to me and might suffice (in addition to legal > arrangements of course) to enable fairly open interoperability. > > Some thought on how existing profiles such as OIO might fit into it > would be needed of course. > ---- > Stephen D Green > > > > On 8 August 2011 09:03, Stephen D Green <stephengreenubl@gmail.com > <mailto:stephengreenubl@gmail.com>> wrote: > > There could be a set of profiles to cover most application capabilities > and each profile could have a URI (or namespace) associated with it > e.g. > > > > > *Profile* > > > > *Benchmark* > > > > *Ceiling* > > > > *ID (URI)* > > > > ABC > > > > - > > > > subset > > > > uri:abc > > DEF > > > > subset > > > > subsetPlus > > > > uri:def > > XYZ > > > > subsetPlus > > > > standard > > > > uri:xyz > > > > > > By profile I here mean conformance profile (subset spec). > > > > (I'm not sure whether the ProfileID or CustomisationID in UBL > would be the right place to put this in a document. If the right place > is the CustomisationID then maybe it needs to be especially clear > that this is the case to avoid confusion over multiple meanings of > 'profile'.) > > > > > ---- > Stephen D Green > > > > On 7 August 2011 12:28, Stephen D Green <stephengreenubl@gmail.com > <mailto:stephengreenubl@gmail.com>> wrote: > > 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 > <mailto: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> > <mailto: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> > <mailto: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. > <http://docs.oasis-open./>____org/ns/tag/taml-201002/ > > <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>> > <mailto:stephengreenubl@gmail. > <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]