[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-hisc] Re: SV: Human Interface Group -UBL
Thanks for bringing me in line on these distinctions, Jon, At 2006-02-02 08:55 -0800, jon.bosak@sun.com wrote: >You're making me realize that the HISC work per se (the >specifications) should probably be considered one of the >standalone specs, not part of the Support Package. Bingo! I never thought of it that way. >| And as I mentioned before, specifications are static while >| implementations evolve ... if we included any implementation in >| the package, it won't be long before that implementation would be >| superceded by a new version, yet we won't be going back into the >| package to update it. > >Au contraire, we will indeed be updating the Support Package >periodically as we have further helpful stuff to include. I was unaware. >Another reason to put the HISC specs in their own document. Indeed. >This is actually the same distinction we've already arrived at >between the code list specification and the code list support >files. So it is ... thanks again for putting me back on track regarding this. That would mean, then, moving "Output formatting specifications (may not include all doctypes)" and "Input mapping specifications (may not include all doctypes)" from "UBL 2.0 Support Package" to "Standalone supporting specifications", and leaving "sample XForms" in the "UBL 2.0 Support Package". I suppose I could put Crane's stylesheets in the support package if the package is being revised periodically, though that would take traffic away from my web site which is one of my goals in having made them available for free ... so I'll have to think about this. However, I would still like to see the support package point to a dynamic web page that lists all known implementations. That page would be updated far more often than the support package. Oh, a thought though ... does this give too much weight to the output and input specifications? They are, after all, only meant to be guidelines. Do they "deserve" to have Committee Specification status? If not, then their role is back in the support package, though the distinction will still need to be made and HISC's commitment will still be limited to the specifications. I'm curious to know how people feel about how much weight these example specifications have, as that will inform the decision to make them standalone or just part of the support package. I like that the support package will have a life of its own with periodic revision. . . . . . . . . . . . . . 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]