Proposed overview/scope of work for OPC revision

[MURATA Makoto]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20140204/f7c5781c/attachment.html>