Proposed overview/scope of work for OPC revision

[MURATA Makoto]

In the BRM, it was agreed that OPC conformance is
data conformance rather than application conformance.
This decision is captured by the last sentence in Clause 2.

However, requirements in Part 2 are stated as requirements
on package implementers, format designers, format
producers, and format consumers.  This is because of the
lack of time in the BRM.  Every  requirement should be
reworded as a requirement on OPC packages.   From
the beginning, conformance requirements on format
designers are doubtful.  Moreover, the classification
into four types of players is doubtful and it unnecessarily
tie the hand of implementors.

I think that all requirements should be reworded as
requirements on packages and Annex H should
be dropped.

Regards,
Makoto



2014-02-05 Rex Jaeschke <rex at rexjaeschke.com>:

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



-- 

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/20140205/39c29c6a/attachment-0001.html>