I think a run-time artifact should be more compact.
The TA characteristics you are describing seems to me more useful for a library of TAs.
It's just my opinion...
thanks for your efforts with this !
Roberto
StephenGreen ha scritto:
4ABA1689.3A62.00C2.0@bristol.gov.uk" type="cite">I wouldn't disagree with any of this but just to note I'm working with TAG TC at the moment (still too early to predict success) on modularity of test assertions. Take for instance my package of assertions (latest version: http://www.oasis-open.org/committees/download.php/34299/ubl-ta-draft-0-71.xml ) These assertions could be a core set and another set in another file could reference these as test assertion external references. The set of assertions which references the core could be part of a customisation and could qualify the core assertion main set of any set (test assertion set) with prerequisites (which have to be true for the referenced assertions to be considered relevant for testing). The latest draft of the Test Assertion Markup Language (v0.7) http://wiki.oasis-open.org/tag/TestAssertionMarkupLanguage?action=recall&rev=11 has what I hope might prove to be the necessary constructs (testAssertionRef and children) for making such refs to external test assertions (see bottom of this archive of my email to TAG TC http://lists.oasis-open.org/archives/tag/200909/msg00041.html ) It's early days but there are other groups already making use of this kind of test assertion methodology, just not yet using this particular markup. Admittedly external test assertion references in executable test assertions might be a bit advanced so need to proceed carefully. Best regards Stephen D GreenJAVEST by Roberto Cisternino <roberto@javest.com> 22/09/09 22:41I think we should provide "at least" the main assertions to avoid people confusion. There are information very easy to map in UBL, others are more difficult. Many people do not read UBL annotations available on each schema, this reason it is easy to get confused by some data structures. The profile should not broke the main structure provided for UBL documents. Profiles should not broke main concepts... It is fine we do not apply too many mandatory fields, but some relevant data should be clearly mentioned in the specification and I think there is a small set of assertions that we should provide (at least as a written indication) To explain me better, I think we should print the annotations of some relevant information items in the specification, to underline the use of that specific information. --- Oriol Bausà ha scritto:I do not know if we can do this on the full UBL data model... maybe this has to be done when working on customizations... El 18/09/2009, a las 15:00, Stephen Green escribió:What we lack is the conformance profiles which close them off with a conformance profile and make them concrete for testing. Or interoperability profiles, etc. So in effect 'just add subset'(andprobable more TAs). How much of this do we want to do?
Nessun virus nel messaggio in arrivo. Controllato da AVG - www.avg.com Versione: 8.5.409 / Database dei virus: 270.13.112/2388 - Data di rilascio: 09/22/09 05:51:00
--
PPlease consider the environment before
printing this email.
JAVEST by Roberto Cisternino
* Document Engineering Services Ltd. - Alliance Member * UBL Italian Localization SubCommittee (ITLSC), co-Chair * UBL Online Community editorial board member (ubl.xml.org) * Italian UBL Advisor
Roberto Cisternino
| mobile: +39 328 2148123 | |
| skype: roberto.cisternino.ubl-itlsc | |
| [UBL Technical Committee] | http://www.oasis-open.org/committees/ubl |
| [UBL Online Community] | http://ubl.xml.org |
| [UBL International Conferences] | http://www.ublconference.org |
| [UBL Italian Localization Subcommittee] | http://www.oasis-open.org/committees/ubl-itlsc |
| [Iniziativa divulgativa UBL Italia] | http://www.ubl-italia.org |