OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[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

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]