Proposed overview/scope of work for OPC revision

[Arms, Caroline]

I'm going to echo Rex's comments on Annex H. As far as I'm concerned, the arguments made to have it in the first place still apply.

Caroline

Caroline Arms
Library of Congress Contractor
Co-compiler of Sustainability of Digital Formats resource
http://www.digitalpreservation.gov/formats/

** Views expressed are personal and not necessarily those of the institution **
________________________________________
From: Rex Jaeschke [rex at RexJaeschke.com]
Sent: Tuesday, February 04, 2014 11:11 AM
To: 'SC34'
Subject: RE: Proposed overview/scope of work for OPC revision

Recording your second point Murata-san, of course Annex H has no new requirements; it’s clearly marked as being informative!

For convenience, all the rules are gathered here, so a reader can find them easily by rule number. In order to avoid synchronization errors, the rule text in that annex is not hard-coded; it gets copied verbatim from the normative text via named bookmarks when references are updated.

So, if that annex is not wrong, then it might be useful for some readers (especially those outside of WG4). To those who don’t care to read it, they can simply ignore it. What’s to be concerned about?

And why should all the Parts of 29500 have similar-looking annexes? Clearly, Parts 2 and 3 are quite different from each other and from Parts 1 and 4.

Rex



From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
Sent: Tuesday, February 04, 2014 7:41 AM
To: John Haug
Cc: SC34
Subject: SPAM-HIGH: Re: Proposed overview/scope of work for OPC revision

OPC conformance has been an issue even before the BRM.
Although there were a number of improvements in the BRM,
I still have two concerns.

First, although OPC conformance is now defined as purely
data conformance, many sentences in OPC look like application
conformance.

Second, Annex H
provides copies of normative sentences in the body, without
any new requirements.   No other parts of OOXML have such
Annex.

Regards,
Makoto

2014-01-08 John Haug <johnhaug at exchange.microsoft.com<mailto:johnhaug at exchange.microsoft.com>>:
To reach consensus on scope and to better understand what we’re intending to accomplish before we get lost in details, may I suggest the following as the list of topics we want to address in our changes to Part 2?  All open DRs marked for Part 2 should be included below.  Anything to add/remove/change before we agree on what we’re going to do?

I’m going to try to organize a set of reference info, more thorough than the short list I sent out quickly on Thursday, to include numerous of old e-mail threads, documents, etc.  If I am able to do so, I may put it on a new Wiki page on the WG 4 Assembla wiki (https://www.assembla.com/spaces/IS29500/wiki).  I would also add the below, plus changes.


1. Combining IRI/URI

•         09-0280 – general DR about sections of OPC assuming non-ASCII is disallowed

•         09-0281 – terminology; all uses of “part” should specify what kind of part is meant

•         09-0283 – similar to 09-0280

•         09-0284 – terminology; need to re-associate the ABNF term names with the prose for part names

•         09-0285 – terminology; use of “part IRI” and “part URI”

•         09-0286 – need to update 9.2 (Part Addressing) to specify the format of a reference, based on the changes to be made to 9.1.1 (Part Names)

•         09-0288 – same as 09-0286, but for 9.3.2 (Relationship Markup)

•         09-0291 – terminology; specify what “Unicode string” means, based on the changes to be made to 9.1.1

•         09-0292 – which characters are allowed in a part name (e.g., whitespace, delimiters, special characters)

•         13-0002 – fix previous changes made to Annex H for introduction of non-ASCII support

•         Add cautionary language noting that implementations might only support ASCII/URIs?  Anything to note in Part 1?

2. Relative/absolute referencing

•         10-0015 – clarify “source part” for relationships

•         Add cautionary language about detailed interpretations of relative vs. absolute references as defined in RFC 3986?

3. Pack URI

•         09-0293 – decide how, and whether, to handle IANA registration

o   (see also historic info, including issues with Pack URI, here: http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml, http://www.iana.org/assignments/uri-schemes/historic/pack)

4. Digital signatures

•         11-0029 – is content from xmldsig-core duplicated in 13.2.4 (Digital Signature Markup)?

•         11-0030 – update normative reference to xmldsig-core?

•         11-0031 – update reference to xmlsec schema?

•         What, if anything, needs to be said about ensuring XAdES use is allowed?

5. Versioning

•         09-0168 – cannot distinguish between ECMA 1st ed OPC package and later versions (e.g., 29500 supports non-ASCII)

6. Editorial misc

•         12-0001 – unify capitalization of “relationship part”

•         Remove reference to Part 3 from clause 8 (Overview)



--

Praying for the victims of the Japan Tohoku earthquake

Makoto