[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Reflections on Test Suites (like NIST's) and UBL
One thing which needs clarification for complete UBL instance validation, as part of an overall UBL set of validation tools, is what is meant more precisely about no empty elements: precise to the point where yes/no validation can be asserted. For example, does it mean that no ABIE element which is a 'container' may exist when it has no content. If so some examples may be wrong (and it might be possible to have very awkward documents if they have mandatory children but no mandatory children of those children). In the past there have been expressions of a minimal instance, for example, containing an empty Party element since the Party has no mandatory direct children. If this is invalid then the Party has to disappear from an instance when the children all disappear - particular case of containment. This would have ramifications in design decisions for any new document with new ABIEs but that is another matter. This is one way it needs to be clearer what is meant by conformance at instance level, IMO. A bit more controversial is what is conformance in the use of the Extension... These two issues may need resolving before an instance of UBL 2.0 can be automatically and incontrovertibly validated by a NIST or any other tool. Let alone what qualifies as a conformant schema (perhaps only a UBL schema is truly conformant rendering an online test suite irrelevant - is this so?). Importantly I'd add that I've found that it may be impossible with current tools to determine conformance of any instance to UBL 1.0 SBS. The requirement for testing is not very well met at all, it seems to me, by the 2 rules of the SBS (maybe I'm to blame for that but please don't sue me). It may be that the concepts of the SBS inherited in other subsets carry with them such weaknesses if online or offline test suites are ever intended for subset instances. The bit which is difficult or impossible to verify automatically (other than by reasonable human judgment - the use case for SBS, if I remember correctly) is whether an element is properly processed by the receiving application. 'Processed properly' is not (and perhaps cannot be) fully defined. Nearest to it is perhaps the concept 'must understand' but how too can that be automatically tested. Similar issues affecting the scope of the NIST online or offline toolsets I'm guessing might make such tools for UBL inpractical and require some degree of human judgment (e.g on what is conformant use of the Extension). A pity but that seems to be the result of normal business practice and current business software design. Is there scope for this to change to allow us to move closer to fully automatic conformance testing of UBL documents? It may mean a compromise on how subsets and customisations work which is currently unacceptable to mainstream business and auditing. Best regards -- Stephen D. Green Partner SystML, http://www.systml.co.uk Tel: +44 (0) 117 9541606 http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice Quoting stephen.green@systml.co.uk: > [Reflections on Test Suites (like NIST's) and UBL: What I'd like to see...] > > UBL TC and NIST might note TaMIE TC and TAG TC work which attempts > to provide frameworks for authoring test assertions and a test > scripting language applicable to documents (besides other things). > > (See TAG TC and TaMIE TC wikis: > http://wiki.oasis-open.org/tag/FrontPage > http://wiki.oasis-open.org/tamie/FrontPage ) > > I hope these lead to markup which UBL could use (1) to formally > document rules based on conformance testing requirements. UBL use > was a use case for TAG (e.g. SBS, customisation profiles, etc). > > Not all rules can be stated with Schematron. Test Assertions include > the designation of prerequisites to a test assertion implying one > test assertion outcome can depend on the outcome of another test > assertion. > > A test scripting language can take a set of test assertions (in XML) > and using something even as simple as XSLT generate a test script > which a test suite or testing and monitoring process (like TaMIE's) > can use to test internet document exchanges in an SOA environment. > > SET TC might deliver further rules in ontologies for inclusion of > context in these scenarios. All these things may eventually combine > in an architecture based on OASIS open standards, etc to provide a > testing and monitoring framework suited to UBL and derivative > document engineering and exchange. So I hope. > > I hope too that all this will blend well with what organisations > such as NIST are developing. > > I just suggest the UBL business and conformance rules take all this > into account. > > All the best > > Steve > > Reference > 1. Markup prototype DTD > http://lists.oasis-open.org/archives/tag-comment/200805/msg00002.html > > -- > Stephen D. Green > > Partner > SystML, http://www.systml.co.uk > Tel: +44 (0) 117 9541606 > > http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice > > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]