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

[Francis Cave]

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

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20141213/c7cfb71f/attachment.html>