Let me try again: DR 13-0002

[MURATA Makoto]

Dear colleagues,

Inspired by Caroline, I studied Annex H again.  I
tried to be more thorough than before.

I propose to remove Annex H and introduce a new
informative Annex "Guidelines for Format Designers".

Here is my reasoning.

1) Annex H covers about 30% only

Let me demonstrate that Annex H only covers about 30%
of what it should cover.

I constructed KWIC indexes by applying the following
regular expression to the 2011 edition of OPC.

/(should|shall|may|might)/

There are 396 matches preceding Annex H.

But there are 120 entries of the form [Mx.xx] in the
2011 edition of OPC.  A lot of requirements are simply
looked over in Annex H.

2) Requirements on format designers

There are 17 matches of
/[Ff]ormat designers? (should|shall|may|might)/.

I think that they should be put in a new informative
Aneex for "Guidelines for OPC-based formats".

Specifications of such formats should provide
- a list of media types
- a list of relationship types
- restrictions on fragment identifiers and parameters for each media type
- additional requirements on processing

I think that such an annex is more useful than
Annex H.

3) Requirements on producers and package implementors

I believe that almost all of the requirements matching

  /[Pp]roducers? (should|shall|may|might)/

should be rewritten as conformance requirements on
data.  Data conformance requirements can be easily
checked and are thus much better than requirements on
producers.  I believe that the latest draft has been
improved significantly about this.

I guess that quite a few requirements matching

  /[Pp]ackage [Ii]mplementers? (should|shall|may|might)/

should also be rewritten as data conformance requirements.

3) Unnecessary requirements on consumers

Among the 43 requirements on consumers, 23 of them are
of the from "consider ... error".  However, "error" is
never defined in 29500-2.

Q1: Are consumers required to report errors?

I don't think so, since user would be at a loss.  Or,
do OPC libraries of Microsoft use Mx.XX as error
numbers?  If so, please let me know.

Q2: Are consumers required to stop normal processing?

I don't think so, since MS Word tries to recover from
errors in many cases.

If consumers are allowed to do anything when there is
an error, all requirements of the form "consumer
... consider ... error" are useless and can be safely
dropped.

There are 20 other requirements on consumers.  I took
a quick look at them.  I think that most of them can
be reworded as data semantics.  But there might be
some special cases.  In particular, we might want to
differences between OPC digital signature validation
and XML Dsig validation.  This needs further work.


Appendix: Query regular expressions and results

All results are available at
https://www.assembla.com/spaces/IS29500/documents?folder=80101133

1) All requirements

/(should|shall|may|might)/
397 matches
modalVerb.tsv and modalVerb.txt

2) Requirements on format designers

/[Ff]ormat designers? (should|shall|may|might)/
17 matches
formatDesigner.tsv and formatDesigner.txt

3) Requirements on package implementors

/[Pp]ackage [Ii]mplementers? (should|shall|may|might)/
136 matches
packageImplementor.tsv and packageImplementor.txt

4) Requirements on producers

/[Pp]roducers? (should|shall|may|might)/
43 matches
producer.tsv and producer.txt

5) Requirements on consumers

/[Cc]onsumers? (should|shall|may|might)/
43 matchese
consumer.tsv and consumer.txt

6) ... consider ... error

consider NEAR error
22 matches
considerError.tsv and considerError.txt


Regards,
Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20160605/6d173cb2/attachment.html>