Second try -- RE: Action item on additional example for Foreign Part in MCE Best Practices document.

Arms, Caroline caar at loc.gov
Wed Dec 9 22:52:42 CET 2015


My apologies for not getting another draft of this out yet.  I've been swamped with special requests from the Library before the end of my current contract.

Today I got started and realized that I still had questions that might be easier to pose directly rather than in comments on a new draft.

First -- in relation to the foreign/unknown terminology

>From Part 1

"9.1.4 Unknown Parts
With the exception of relationship parts, all other parts in an Office Open XML document that are not the target
of an implicit or explicit relationship are considered unknown parts. Unknown parts shall be ignored on
document consumption and can, but need not, be discarded on production."

***This seems to imply that a part that is given a relationship as Chris suggests is NOT an unknown part.

Again from Part 1
"9.1.7 Unknown Relationships
All relationships not defined within ECMA-376 are considered unknown relationships. Unknown relationships
are permitted within an Office Open XML document provided that they conform to relationship markup
guidelines as defined by the OPC specification. Specifically:
*  Conforming consumers shall not fail to load a document containing unknown relationships.
*  Conforming producers that are also consumers can, but are not required to, roundtrip and preserve
unknown relationships and their target parts."

*** So Chris's recommendation is actually to use an "unknown" relationship type not to use an "unknown part."  So I propose to use the term "foreign part" to mean a part with a relationship type not defined in OOXML.

Does that make sense?

Back to Part 1 on the content type question I raised which no-one responded to.

"9.1.6 Invalid Parts
ZIP archive items that do not conform to OPC part naming guidelines or are not associated with a content type
shall not be allowed in an Office Open XML document, with the exception of items specifically defined by ECMA-
376-2 and trash items."

*** This seems to require a declaration in /[Content_Types].xml that covers the type of the added "foreign" part.  Chris's draft does not mention that requirement.  Do others agree that it is a requirement?  If so, I will extend the discussion of the first example to include that.

I see the following in a minimal .docx file that I created in Word
<Default Extension="xml" ContentType="application/xml"/> 

I'm going to assume that for the .mov file in the example from Chris, the following would be adequate:
<Default Extension="mov" ContentType="video/quicktime"/>
       See https://www.iana.org/assignments/media-types/video/quicktime

Looking at the ONIX documentation for guidance on file extension use:
>From http://www.editeur.org/files/ONIX%203/ONIX_for_Books_Release3-0_html_Best_Practice+codes_Issue_31_v1-2-7.zip
  ONIX file names commonly include the '.xml', '.onix' or '.onx' suffix (the first two are preferred).
  The mime type should typically be 'application/xml', ...

Francis,     Do you have any suggestions as to which of .xml or .onix I should use for the ONIX example?  Or would you recommend covering both possibilities in my example?

I hope to have more time before tomorrow's call to work on revised text.

      Caroline

PS: Apologies for sending a dud message.  My touchpad took control!!

Caroline Arms
Library of Congress Contractor
Co-compiler of Sustainability of Digital Formats resource    http://www.digitalpreservation.gov/formats/

** Views expressed are personal and not necessarily those of the institution **


-----Original Message-----
From: Arms, Caroline [mailto:caar at loc.gov] 
Sent: Friday, November 27, 2015 2:25 PM
To: 'Francis Cave'; e-SC34-WG4 at ecma-international.org
Subject: RE: Action item on additional example for Foreign Part in MCE Best Practices document.

Francis,  Thanks again.  Taking a quick look at the schemas, I'm inclined to use the 'reference' version as an example, because if anyone actually followed things up, they would find tag names that are less cryptic.

I'll plan on doing a next draft, taking into account the feedback so far, sometime next week.  

    Caroline


Caroline Arms
Library of Congress Contractor
Co-compiler of Sustainability of Digital Formats resource    http://www.digitalpreservation.gov/formats/

** Views expressed are personal and not necessarily those of the institution **

-----Original Message-----
From: Francis Cave [mailto:francis at franciscave.com] 
Sent: Friday, November 27, 2015 6:48 AM
To: e-SC34-WG4 at ecma-international.org
Subject: RE: Action item on additional example for Foreign Part in MCE Best Practices document.

After a further exchange with Graham I think that, if we wish to include an ONIX example, we should use 'application/xml' for the media type. We can use the same URI for both namespace and relationship type, so either 'http://ns.editeur.org/onix/3.0/reference' or 'http://ns.editeur.org/onix/3.0/short', depending upon which tag set we choose to use.

Francis



-----Original Message-----
From: MURATA Makoto (FAMILY Given) [mailto:eb2m-mrt at asahi-net.or.jp]
Sent: 27 November 2015 03:30
To: e-SC34-WG4 at ecma-international.org
Subject: Re: Action item on additional example for Foreign Part in MCE Best Practices document.

Francis,

Thank you very much!

A specialized media type for ONIX would make sense if there is some special processing (such as ONIX fragment identifiers). 

So far, in OOXML,  URIs for namespace names and those for relationship types are different.  But I do not see strong reasons for separating them.  
Namespace names should be changed only for intentionally destroy existing application programs for new data.  When should we change relationship names?  Probably,when we would like to prohibit existing OOXML applications from accessing new parts.  Then, it might be a good idea to use the same URI.

I don't think that namespace names or relationship types have to be resolved.  They are just names.  Thus, I don't think that performance is an issue.

Regards,
Makoto




More information about the sc34wg4 mailing list