[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: SV: Human Interface Group -UBL
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]