Re: SV: Human Interface Group -UBL

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

Thanks, Peter, for this input!

At 2006-01-31 18:06 +0100, Peter Larsen Borresen wrote:
>I the package our agency has promissed to release there will be xslt
>presentations and xforms for the document types we intent to base our
>procurement process.

Kewl!

>In stead of intenting theesee would like to contribute
>to UBL so we first help UBL HISC to make a UBL version of this and the make
>a danish subcommitee based on this work.

Tremendous!  Though all HISC needs is the *specifications* of the 
input and output presentations, and then hyperlinks to the your 
agency's implementation of these specifications.

To try and scope HISC to do more than the specification documents 
would stretch the available resources to the point of being unable to 
meet dates.

>By having a UBL up-running version
>it will make it easier for implementers to creating there own by copy, paste
>and modify.

Perfect.  The Danish repository of the working implementations of the 
UBL specifications would be available for implementers all over to 
consider how your agency has satisfied the requirements and guidelines.

There will also be other sources of implementations of the 
requirements and guidelines, available in other repositories, that 
implementers can consider when looking to support UBL.  No one 
implementation should be weighed differently from other available 
implementations of the specifications.

I feel strongly that actually including any particular set of 
implementations in the UBL HISC package is inappropriate, and that it 
suffices that HISC merely point to readily available 
implementations.  The HISC package should be restricted, I believe, 
solely to the specifications of implementation.

>If we do not think about resources, what will be the best way to
>cooperate doing this work?

By prioritizing the effort to first create the specifications of how 
you want the human interfaces to behave, followed later by the 
testing and implementation of those stated behaviours.

>How can we draw the best line between UBL and a
>UBL implementation like the Danish?

I believe by distinguishing the specification of the behaviour of the 
implementation from the actual implementation.  Any efforts expended 
to the organizing, writing, and publishing of the specifications come 
under the purview of HISC, while any efforts expended to their 
implementations could be regarded as either (a) the testing of the 
specification (part of HISC, the deliverable being a confirmation of 
the accuracy and implementability of the specification) and/or (b) 
the satisfaction of Danish objectives of making implementations 
openly available for cut/copy/paste by implementers (not part of 
HISC; the deliverable being the source code and demonstrated behaviours).

Moreover, once the descriptions of the behaviours have stabilized and 
we have published and included HISC formatting specifications in the 
support package, any implementation can evolve, be tested, be 
repaired, be enhanced, etc. on its own schedule outside of HISC 
requirements, without inadvertently "locking in" any particular 
implementation as part of the HISC package.  This isn't an issue if 
HISC merely points to implementations rather than includes any sample 
implementations.  This is yet another compelling reason, I believe, 
to distinguish the specification of the behaviours from the 
implementations of the behaviours as being, respectively, inside HISC 
deliverables and outside.

Hopefully this approach will entice alternative proprietary and 
non-proprietary implementations of the behaviours, again outside of 
HISC deliverables.

>I think at the first meeting we need to
>scope the HICS work so it fulfills the Danish requirement and the ambitions
>of UBL HISC.

The comments above are my own opinions, and I hope they resonate with 
you and other members.  I'm anxious to hear how others feel.  Going 
beyond the above definition of what belongs *inside* HISC from what 
belongs *outside* the committee effort would, I believe, jeopardize a 
meaningful and usable level of success that we should be able to 
achieve in the time available.

I'm anxious that as much of this discussion as possible be done as we 
are talking today over the mail list.  I would like any HISC meeting 
to be merely a confirmation of mail list discussions and an 
opportunity only when necessary to more quickly go into a level of 
detail inappropriate for email.  Lately HISC teleconferences have 
been held in America evening and Asia morning (because at the time we 
thought we would be getting some input from Asia) ... which would be 
inappropriate for European contribution.  Unfortunately, America 
morning and European afternoon meetings are difficult for me to 
attend because of my corporate responsibilities, though these don't 
resume for me until April.

If we find we still need a teleconference, then I'd like to schedule 
a morning/afternoon time next week ... but I have to check with Jon 
as to which morning/afternoon slots are available for us to 
use.  Let's see if we can engage the wider HISC membership through email first.

Thank you again for engaging in this discussion, Peter.

. . . . . . . . . . . . . . Ken

--
Upcoming XSLT/XSL-FO hands-on courses:  Denver,CO March 13-17,2006
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal