OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-hisc message

[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]