RE: SUO: RE: RE: FW: Comment #11 - 'SUO Evolution' -- Resolution
At 10:43 2000-09-18 +0200, West, Matthew MR SSI-GREA-UK wrote:
> Dear Frank,
>
> Thank you. I am very well aware of the standards alternatives and their
> timescales. I have been operating within them for the last 7 years
> developing industry standard data models, and trying to get them improved.
> It is preceisely this expereince which is leading us in ISOTC184/SC4 away
> from traditional standards towards registers.
>
> See comments below.
>
> Regards
> Matthew
I'm sorry if I've mentioned stuff that you are already aware of ... are you also aware of the licensing problems that are associated with using (ISO) standards based on registries? This has become a significant problem for certain industries ... this would definitely be a problem for SUO. Here's the problem in a nutshell: those people using the registry and incorporating its contents in products must pay a licensing fee to ISO (even if there are no embedded intellectual property issues -- see my comments to Bob Spillers). Not all registries have problems like this. However, the ones that have these kind of operational dependencies (even if there is a web site on the internet) may have licensing problems.
I'm also responding to a couple of your points below.
> ... [discussion of revision process for standards ...]
> >
> > - Amendments: These are "small changes" to the
> > standard (i.e., not wholesale revision). Typically, these
> > amendments also include the Technical Corridenda that has
> > been approved previously. Like Technical Corregenda, they
> > can be issued as frequent as the committee desires, but I
> > don't see the committee issuing more than two amendments a year.
>
> MW: But I am anticipating major extensions during each quarter over a number
> of years. Say about 100 terms per quarter. More than should be acceptable
> for an amendment.
This kind of incremental improvement is OK for amendments. If you compare it to ISO 10646-1, Universal Character Sets, they added a handful of languages with each amendment (there are over a dozen amendments).
> Of course you can issue a series of parts, but then each part takes about 5
> years.
I'm not sure where you are getting the "5 years" from. Any standard can be developed in a very short amount of time: from about 4 months to 9 months, depending on the standards development organization (includes ISO/IEC, too).
The "5 year" timeframe concerns the maximum time in which a standard must come under review. At this review point, the standard is then revised (new technology), reaffirmed (stable technology, like ASCII), or withdrawn (obsolete technology, like punched cards).
> > - Revisions: Signigicant changes may be incorporated
> > into the review cycle.
> >
> > Many people misinterpret the "5-year review cycle": 5 years
> > the the *maximum* time in which a standards may be revised,
> > reaffirmed, or withdrawn. The committee may revise a
> > standard sooner than 5 years.
>
> MW: Yes I know this. 5 years is what I have seen in practice as the average
> time to create a standard in this area from New Work Item. I know it can be
> done much quicker theoretically, but that assumes you are standardising
> something that is well established in the first place, or is in some sense
> arbitrary. This is not the situation we have here.
As you point out, the time it takes to develop a standard is dependent on many factors. I cannot give a reasonable estimate for SUO. I don't believe we would maintain the long-term participation (not to mention the support of the standards development organization) if we took more than 5 years. I doubt this process will be less than 2 years.
> ....
> > There are some significant benefits for using this process:
> >
> > - Implementors of SUO-conforming products and
> > services can clearly identify what they conform to, e.g.,
> > "IEEE 2345F:2003" means that the implementation conforms to
> > all the amendments up to "F".
> > - Consumers can clearly state their needs (from a
> > procurement perspective), e.g., "products shall conform to
> > IEEE 2345F:2003".
> > - Purchasers of the standard get all the current
> > Technical Corrigenda and Amendments by simply asking for "IEEE 2345"
>
> MW: Yes I agree with these advantages, but they are important for what is
> going to be implemented as software, not what will be implemented as data. I
> expect that the SUO will be a data fill for some different sorts of
> applications, rather than be embedded in software.
These advantages are just as important for standards committees that develop code sets (red=1, orange=2, yellow=3, etc.), which are much simpler projects than the SUO.
> > Registries can operates as the same speed as the Technical
> > Corrigenda and Amendment process, but the registry has no way
> > of identifying the "configuration management" (version)
> > issues, such as "which set of features are included?".
>
> MW: This is not necessarily true. It depends on the standard that governs
> the the register and the way it is administered.
Could you given an illustration of such a registry that handles configuration management? The configuration management aspect is really important for industrial grade systems.
> > You might not think this (the "configuration management"
> > issue) matters much, but it will matter:
> >
> > - If you are a vendor and you lose a contract because
> > your system did not conform (if you can't point to all the
> > features than it's hard to know whether or not you conform to
> > the standard)
>
> MW: Again, it depends what you think people will deliver. I expect
> conforming software to be delivered that utilises the SUO. It is then up to
> the customer to use the latest version of the SUO (or not).
Which points back to my comments above? How does the customer make sure the have the *right* version?
> > - If you are a consumer and you didn't get the
> > interoperability you expected (you believed you had asked for
> > "standards conforming" products, but they don't interoperate
> > ... it's hard to expect interoperability when you don't know
> > exactly what features have been incorporated into vendors' products)
>
> MW: This will be up to the users. Since the lates version would be available
> electronically, and probably on the internet, there will not be much excuse
> for using an out of date version. A registration body could even provide a
> service to notify of updates.
This sounds great, but it doesn't scale up in real-world systems. There is a real need to know what version is being used and to manage change. If it is available electronically, that still doesn't imply that it is usable (unless there is some data interchange format, like KIF).
> MW: Bottom line here is that we seem to have some different ideas about what
> sort of standard we are developing and how it will be used. Given that, I
> think we should have some further discusion on this point so we have a
> common understanding of what it is that will be standardised, and what
> conformance will mean.
Ah .... "conformance" ... you've touched on one of my favorite topics. I've said many times:
"You don't really understand a standard until you understand it's conformance clause."
We *should* have this discussion ... but I believe it is more appropriate to have this discussion while we are developing the standard, not for development of the Scope and Purpose. We understand conformance enough now to agree upon a Scope and Purpose. Once we start developing the standard, we'll have to craft standards wording for the conformance clause ... a lively discussion in virtually every standards committee. :-)
-FF
-----------------------------------------------------------------------
Frank Farance, Farance Inc. T: +1 212 486 4700 F: +1 212 759 1605
mailto:frank@farance.com http://farance.com
Standards, products, services for the Global Information Infrastructure