30114-2: ignorables, app-defined ext elems, or custom OPC parts

[MURATA Makoto]

Dear colleagues,

I think that we should rely on additional OPC parts rather than
app-defined ext elems or MCE.

The rest of this mail describes an alternative to the first CD.
The idea is very simple.  Introduce an empty part as the origin
of character checking.  From this empty part, reference a
Character Checking Condition part.  It references another
part, which is the target of character checking, and also
specifies a CREPDL script (19757-7).  Since I used OPC
digital signature as a basis, I used an attribute for referencing
the target part.  But we might want to rely on relationships.



5.1 General

The character chedking parts consist of the Character Checking Origin
part and Character Checking Condition parts.  Relationship names and
content types relating to the use of digital signatures in packages
are defined in Annex E.

Figure X–X shows a package with the Character Checking Origin part and
two Character Checking Condition parts.  The example Character
Checking Origin part references two Character Checking Condition
parts, each containing a CREPDL script.

Editor's Note: This figure is very similar to Figure 12–1 in Part 2.

5.2 Character Checking Condition part

A Character Checking Condition part has a Reference, Location, and a
Condition element in this sequence.

5.2.1 Reference element

Note: This is similar to the Reference element in OPC.

<Reference URI="/document.xml?ContentType=application/
            vnd.ms-document+xml">

5.2.2 Location element

A location element optionally specifies locations in the referenced
part.  Character contents at the specified location are subject to
character checking.

At present, a location element has no elements and attributes, and
is assumed to specify the entire part.

5.2.3 Condition element

A Condition element has a CREDPL script as defined in ISO/IEC 19757-7
as the only child element.

5.2.4 Processing model

Visit each Character Checking Condition part in sequence.  Check
the character content at the specified location against the
CREPDL script in the Condition element.

Annex A (normative) Schemas - W3C XML Schema

Annex B (informative) Schemas - RELAX NG

Annex C (normative) Standard Namespaces, Content Types , and Relationship
Types

C.1 Namespaces

http://schemas.openxmlformats.org/officeDocumentExtension/2015/characterCheckingConstraint

CREPDL

C.2 Content Types

Character Checking Conndition part
 application/vnd.openxmlformats-extension.character-checking-condition

Character Checking Origin part
 application/vnd.openxmlformats-extension.character-checking-origin

C.3 Relationshp Type

http://schemas.openxmlformats.org/officeDocumentExtension/relationships/2015/characterCheckingConstraint


Regards,
Makoto


2014-12-14 5:32 GMT+09:00 MURATA Makoto <eb2m-mrt at asahi-net.or.jp>:

> Francis,
>
> We discussed your experiment (thanks!) in the last teleconf.  Here is my
> note
>
> There was a discussion about custom metadata.  Francis Cave reported
> that some implementations do not preserve custom metadata parts even
> if they are referenced by package relationships.  We considered the
> use of MCE for representing custom metadata, but we find that "11.3
> Support for Versioning and Extensibility" in 29500-2 prohibits such
> use.  Rather, this subclause recommends "creating a new part and using
> a relationship with a new type to point from the Core Properties part
> to the new part".  We thus agreed (1) to use a relationship from the
> Core Properties part to a custom metadata part, and (2) to introduce a
> note for preserving valid relationships as well as targets of such
> relationships.
>
>
> Regards,
> Makoto
>
>
> 2014-12-14 0:49 GMT+09:00 Francis Cave <francis at franciscave.com>:
>>
>> If you remember, I experimented with adding foreign OPC parts to hold
>> ONIX metadata. Recent versions of MS Office don’t appear to throw away such
>> foreign parts, but the version of LIbreOffice that I tested does appear to
>> throw them away.
>>
>>
>>
>> Nevertheless, I think we should explore the idea of using a foreign OPC
>> part for character repertoire checking data, as this avoids the need to
>> embed such data in content. I prefer this approach to the use of
>> application-defined extension elements or ignorable elements. As you say,
>> so far as implementations of the existing standard are concerned, new
>> application-defined extension elements would have to be in ignorable
>> namespaces, otherwise the implementations would be broken.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Francis
>>
>>
>>
>>
>>
>>
>>
>> *From:* eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] *On Behalf Of *MURATA
>> Makoto
>> *Sent:* 13 December 2014 08:32
>> *To:* SC34
>> *Subject:* 30114-2: ignorables, app-defined ext elems, or custom OPC
>> parts
>>
>>
>>
>> Summary: Avoid ignorable elements but use application-defined
>>
>> extension elements or additional OPC parts instead.
>>
>>
>>
>> I have thought that we should use ignorable elements for representing
>>
>> data for character repertoire checking.  The first CD does use them.
>>
>> This approach is easy to standardize and implement, but existing
>>
>> implementations will surely throw away data for character repertoire
>>
>> checking.  I have stupidly thought that this is OK.  But no users are
>>
>> willing to use what is thrown away by existing MS Office and Libre
>>
>> Office.
>>
>>
>>
>> The use of application-defined extension elements ensures that data
>>
>> for character repertoire checking is preserved.  But locations of
>>
>> application-defined extension elements are already set in stone, and
>>
>> cannot be changed without making existing implementations
>>
>> non-conformant.
>>
>>
>>
>> Another option is to use additional OPC parts.  If implementations do
>>
>> not throw away targets of valid relationships, data for character
>>
>> repertoire checking is preserved.
>>
>>
>>
>> I can imagine that the use of additional OPC parts has its own
>>
>> problems.  But we should try seriously.
>>
>>
>>
>> Regards,
>>
>> Makoto
>>
>>
>>
>>
>>
>
>
> --
>
> 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/20150207/0f0e3153/attachment-0001.html>