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

[MURATA Makoto]

I created a proposed rewrite.  Unlike the first CD, no MCE constructs are
used.
Rather, OPC parts are used heavily.

Regards,
Makoto



2015-02-07 19:21 GMT+09:00 MURATA Makoto <eb2m-mrt at asahi-net.or.jp>:

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



-- 

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/20150219/8ef31781/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SecondCD.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 54514 bytes
Desc: not available
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20150219/8ef31781/attachment-0001.docx>