Proposed overview/scope of work for OPC revision

Rex Jaeschke rex at RexJaeschke.com
Tue Feb 4 17:11:33 CET 2014


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 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20140204/307d8b1c/attachment-0001.html>


More information about the sc34wg4 mailing list