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

[MURATA Makoto]

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