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

["Stephen Green" <stephengreenubl@gmail.com>]

> 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