Let me try again: DR 13-0002

[MURATA Makoto]

I would like to propose a new Annex H "Guidelines for Format Designers",
available at:

https://goo.gl/gzIX9y

Regards,
Makoto

2016-06-05 19:04 GMT+09:00 MURATA Makoto <eb2m-mrt at asahi-net.or.jp>:

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



-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20160608/5d999f12/attachment.html>