Re: [ubl-hisc] Re: SV: Human Interface Group -UBL

[jon.bosak@sun.com]

I agree with Ken that the specification of behavior (in this case,
data input) is conceptually distinct from the implementation (in
this case, XForms), and I also agree that the former belongs to
the HISC and the latter does not.  But I don't see why we can't
include the XForms in the support package; we're already set to
include the Danish use cases, for example.

Jon

   Date: Tue, 31 Jan 2006 15:12:47 -0500
   From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
   Sender: ubl-hisc-return-182-jon.bosak=sun.com@lists.oasis-open.org
   Cc: UBL HISC <ubl-hisc@lists.oasis-open.org>

   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