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


[gkholman@CraneSoftwrights.com:]

| Oh, I can probably be convinced that it is fine to include the
| XForms in the package if the effort to do so doesn't detract from
| the completion of the specification components that are critical
| to the HISC package.

I was agreeing that the XForms themselves shouldn't be part of
HISC work.

| But I am reluctant to do so because it might blur the committee
| responsibilities, plus it would bias the XForms implementation of
| the input specs to other proprietary and non-proprietary
| implementations ... pointing from the package to a dynamic web
| page maintained by HISC of implementations of input and output
| specs would put all implementations on a level ground.

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.

| 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.  Another
reason to put the HISC specs in their own document.

This is actually the same distinction we've already arrived at
between the code list specification and the code list support
files.

Jon


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]