RE: [tag-discuss] Re: Reasons to wait on convening a TC

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

OK, some rather lengthy opinion of mine below (I'll shut up for a while
after this...)

> DP>What of a WG that doesn't have any XML expertise? 

If we produce a guide that first defines a "TA model" (remember, there
is first and foremost a main "public relation" agenda behind all this:
to convince a large spectrum of spec writers that TAs are good for them,
that they can do it and are even the most qualified for doing it ;-) ,
then they should be able in a first phase to design a set of TAs just
based on this model - no XML or other script involved. That would
already be a great achievement for us if the model itself is adopted by
many, even if just for human consumption e.g. for producing a set of
structured yet text-based TAs in a spec appendix.

Then an XML (or other) representation doesn't have to make that harder
for them, *if* this TA mark-up sticks to the model. Ideally users should
be able to use a form-based tool helping them capture TAs and their
dependencies, etc. and generating this XML representation for them. 

Agree that at this point such usage of XML is still mostly wrappers of
descriptive text - but you wouldn't believe how useful an HTML
publishing can be here compared to plain text (I am talking of a live
XSLT-produced document with cross-indexes etc. able to show you
immediately all TAs pre-requisites to another TA, to automatically index
TAs based on various groupings e.g. conformance profiles, spec modules,
implementation role, etc.)

Beyond this, *some* specifications may lend themselves to more advanced
mark-ups (e.g. involving XPath or Schematron, if the material under test
is XML) That could be done by extending the basic mark-up outlined
above. But I'd say that is stepping  more into fully executable test
case territory. There , yes, more expertise would be needed - and more
dependencies to the nature of the spec. 

So I believe that a "first step" ("just TAs", or "TAs for dummies")
should be very broadly and easily applicable by most users, even with
its mark-up. We could say in the TC charter that this base mark-up (or
whatever scripting) should plan for extensibility points that some specs
may exploit for more ambitious purpose like test cases.

 Jacques

-----Original Message-----
From: Stephen Green [mailto:stephengreenubl@gmail.com] 
Sent: Tuesday, November 28, 2006 10:14 AM
To: tag-discuss@lists.oasis-open.org
Subject: Re: [tag-discuss] Re: Reasons to wait on convening a TC

> DP>What of a WG that doesn't have any XML expertise? Wouldn't
> >[defining the TA format as an XML vocabulary]
> >be making it unecessarily hard for them?
>
> It's possible that TAs will only apply to a subset of the type of
specs
> issued by OASIS, W3C, OMG, and the like. (BTW, XML knowledge is
effectively
> mandatory for spec editors at the W3C.) This gets back to the
"testable
> sentences" remark I made earlier. I'm pretty sure that the hard part
about
> composing well-formed TAs is formulating the contingencies and
conclusion
> (or whatever the various parts will be named) to be suitably rigorous.
On
> the other side, there may already be vocabularies for "rules" that
have
> already solved all aspects of the TA problem other than TA-specific
markup.
> .................David Marston

This is also of interest, not just for a TC's spec but, where
appropriate, for
implementation guides for existing specs. My use case is a language such
as UBL where best practise in using it for certain situations might well
be
one of the deliverables of a TC. In this case the 'spec' is largely
embodied
in a set of XML artefacts which can all be easily referred to using
XPath
and this lends itself to the formation of TAs. Why not just write
Schematron
schemas? Well not all TAs lend themselves to Schematron whereas some
which do could best be written down in some XML format which allows easy
generation of Schematron but also of other artefacts such as generation
of
code where appropriate. Then there is the use case that rules engines
such
as DROOLS might need to be 'fed' with the rules in as close to a
normative
fashion as possible. When state alignment between automated discreet
systems is the main requirement (as might be the case with UBL or other
ebXML payloads) then some guarantee, as much as possible, that rules
determining success or failure for both systems are found and used in an
artefact which is outside both and directly usable by both in the same
way
to the same effect seems at least prudent. In short a set of TAs, with
visibility
and equalivalent meaning to both systems is important to such a B2B
application architecture. Sometimes this all has legal implications
(such as
when there is a dispute over non-payment in an invoicing process) in
which
case having the TAs such that legal technicians can read them as well as
software and rules engines seems prudent. If everyone uses the same way
of defining these TAs - not just TCs in OASIS, say - then there is
better hope
that disputes can be resolved at lower cost to those involved. A nice
thought.

All the best

Stephen Green
SystML

---------------------------------------------------------------------
To unsubscribe, e-mail: tag-discuss-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: tag-discuss-help@lists.oasis-open.org