On Annex G of 29500-2

Chris Rae Chris.Rae at microsoft.com
Wed Sep 17 18:49:44 CEST 2014


This looks like another topic for next week but, on initial investigation, I agree. Annex H [Murata-san, I think you were off-by-one] is far too wordy and data-focused to be informative, and only contains information repeated elsewhere. I think there might still be a use for a truly informative description of OPC packages, but something much more high-level along the lines of “A valid OPC package contains data stored in parts (9.1), indexed in a Content Types Part (9.1.2), and references from parts to other parts are made using relationships (9.3) defined in a Relationships Part (9.3.1). All content is stored in a physical package (10).” I can see some value in some sort of drawn-out version of that, but not the normative-style declarations in the current Annex H.

We’d need to remove all reference to “conformance requirements” in clause 2, as these requirements were only specified in an informative annex. Which is a bit odd in itself.

Chris

From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
Sent: 14 September 2014 19:43
To: SC34
Subject: On Annex G of 29500-2

Folks,

I would argue that Annex G (Guidelines for Meeting Conformance)
should be dropped and that Clause 2 (Conformance) should be
modified accordingly.

First, Annex G adds nothing new.  It merely repeats what is
already stated elsewhere.

Second, Annex G is a partial and misleading list of
requirements.  This is because it is very difficult or even
impossible for Annex G to repeat all requirements in the body.
For example, some of the requirements (e.g, permissible
locations of isegments) in the EBNF have never been captured by
Annex G.

Third, maintaining Annex G in accordance with the body is a
heavy burden for this revision.

Fourth, I believe that standards on data should focus on
requirements on data rather than those on applications.  In
fact, Clause 2 already says "OPC conformance is purely
syntactic."  Requirements on creators should always be captured
as requirements on data.  Some requirements on consumers may be
rewritten as recommendations to consumers.


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


More information about the sc34wg4 mailing list