From 95b98d4f09bd3ce107f6fb52f6edc391a3240408 Mon Sep 17 00:00:00 2001 From: Laurent Le Meur Date: Thu, 27 Dec 2018 23:56:04 +0100 Subject: [PATCH 1/4] Add first draft of ocf-lite --- spec/ocf-lite.html | 564 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 564 insertions(+) create mode 100644 spec/ocf-lite.html diff --git a/spec/ocf-lite.html b/spec/ocf-lite.html new file mode 100644 index 0000000..20a3d85 --- /dev/null +++ b/spec/ocf-lite.html @@ -0,0 +1,564 @@ + + + + + Packaged Web Publication Format (PWP) 1.0 + + + + + + + + + +
+

This specification defines a file format and processing model for encapsulating the set of related resources that comprise a simple Web Publication into a single-file container, the Web Publication Container.

+ +

This specification defines the rules for structuring the file collection in the abstract (the "abstract container") and the rules for the representation of this + abstract container within a ZIP archive (the "ZIP container").

+
+
+
+

Introduction

+

A Web Publication Container is used:

+ + + +
+

Terminology

+ +

Terms with meanings specific to the publishing industry are capitalized in this document (e.g., "Reading + System"). A complete list of these terms and + definitions is provided in [[!WEBPUB1]].

+ +

Only the first instance of a term in a section is linked to its definition.

+ +

In addition, the following terminology is defined for use in this specification:

+ +
+
File Name
+
+

The name of any type of file within an PWP Abstract Container, whether a directory or + a file within a directory.

+
+
PWP Abstract + Container
+
+

The PWP Abstract Container defines a file system model for the contents of the PWP ZIP Container, as defined in PWP Abstract Container.

+
+
PWP Processor
+
+

A software application that processes PWP ZIP Containers according to the requirements + of this specification.

+
+
PWP ZIP Container
+
+

The ZIP-based packaging and distribution format for EPUB Publications, as defined in PWP ZIP Container.

+

PWP ZIP Container and EPUB Container are synonymous.

+
+
Path Name
+
+

For a given directory within the PWP Abstract + Container, the string holding all directory File Name in the full path + concatenated together with a / (U+002F) character separating the + directory File Names.

+

For a given file within the PWP Abstract Container, the Path Name is the string holding all + directory File Names concatenated together with a / character separating the + directory File Names, followed by a / character and then the File Name of the + file.

+
+
Root Directory
+
+

The root directory represents the base of the PWP Abstract Container file system. This + directory is virtual in nature: a EPUB Reading System might or might not generate a + physical root directory for the contents of the PWP Abstract Container if the contents are + unzipped.

+
+
+
+ +
+ +
+
+

PWP Conformance

+ +
+

Container Conformance

+ +
    +
  • +

    An PWP Abstract Container MUST meet the conformance + constraints defined in PWP Abstract + Container.

    +
    • +
  • +

    An PWP ZIP Container MUST meet the conformance constraints + defined in PWP ZIP Container.

    +
    • +
+ +
+ +
+

Reading System Conformance

+ +

An PWP compliant Reading System MUST meet all of the following criteria:

+ +
    +
  • +

    It MUST process the PWP ZIP Container in conformance with all Reading + System conformance constraints expressed in PWP ZIP + Container.

    +
    • +
  • +

    It MUST process the PWP Abstract Container in conformance with all Reading + System conformance constraints expressed in PWP Abstract + Container.

    +
    • +
+ +
+ +
+
+

PWP Abstract Container

+ +
+

File and Directory Structure

+ +

The virtual file system for the PWP Abstract Container MUST have a single common Root + Directory for all of the contents of the container.

+ +

The PWP Abstract Container MUST include a file named entry.html located into + the Root Directory, which contains the Primary Entry Page of the Web Publication. The Web Publication Manifest MUST NOT be embedded in the Primary Entry Page.

+ +

The PWP Abstract Container MUST include a file named manifest.jsonld located into + the Root Directory, which contains the Web Publication Manifest.

+ +

Requirements for the contents of both files are described + in Web Publication Manifest.

+ +

All other files within the PWP Abstract Container MAY be in any location descendant from the Root + Directory. + +

+ +
+

Relative IRIs for Referencing Other Components

+ +

Files within the PWP Abstract Container MUST reference each other via relative IRI references + ([[!RFC3987]] and [[!RFC3986]]).

+ + + +

For relative IRI references, the Base IRI [[!RFC3986]] is determined by the relevant language + specifications for the given file formats. For example, CSS defines how relative IRI references work + in the context of CSS style sheets and property declarations [[!CSSSnapshot]].

+ +
+

Some language specifications reference Requests For Comments [[RFC]] that preceded [[RFC3987]], + in which case the earlier RFC applies for content in that particular language.

+
+ +

For instance, the Base IRIs expressed within the manifest.jsonld + file use the Root Directory of the PWP Abstract Container as the default Base IRI.

+ + + +

then the path illustrations/datatypes.svg is relative to the root directory for the PWP + Abstract Container. + +

All relative IRI references MUST resolve to resources within the PWP Abstract Container (i.e. at or + below the Root Directory).

+ +
+ +
+

File Names

+ +
+

This section is identical to its sibling in [[!OCF32]].

+
+ + +

The File Name restrictions described in this section are designed to allow Path Names + and File Names to be used without modification on most commonly used operating systems. This + specification does not specify how an PWP Processor that is unable to represent PWP File and + Path Names would compensate for this incompatibility.

+ +

In the context of an PWP Abstract Container, File and Path Names are case + sensitive and MUST meet all of the following criteria:

+ +
    +
  • +

    File Names MUST be UTF-8 [[!Unicode]] encoded.

    +
    • +
  • +

    File Names MUST NOT exceed 255 bytes.

    +
    • +
  • +

    The Path Name for any directory or file within the PWP Abstract Container + MUST NOT exceed 65535 bytes.

    +
    • +
  • +

    File Names MUST NOT use the following [[!Unicode]] characters, as these + characters might not be supported consistently across commonly-used operating systems:

    +
      +
    • +

      SOLIDUS: / (U+002F)

      +
      • +
    • +

      QUOTATION MARK: " (U+0022)

      +
      • +
    • +

      ASTERISK: * (U+002A)

      +
      • +
    • +

      FULL STOP as the last character: . (U+002E)

      +
      • +
    • +

      COLON: : (U+003A)

      +
      • +
    • +

      LESS-THAN SIGN: < (U+003C)

      +
      • +
    • +

      GREATER-THAN SIGN: > (U+003E)

      +
      • +
    • +

      QUESTION MARK: ? (U+003F)

      +
      • +
    • +

      REVERSE SOLIDUS: \ (U+005C)

      +
      • +
    • +

      DEL (U+007F)

      +
      • +
    • +

      C0 range (U+0000 … U+001F)

      +
      • +
    • +

      C1 range (U+0080 … U+009F)

      +
      • +
    • +

      Private Use Area (U+E000 … U+F8FF)

      +
      • +
    • +

      Non characters in Arabic Presentation Forms-A (U+FDDO … U+FDEF)

      +
      • +
    • +

      Specials (U+FFF0 … U+FFFF)

      +
      • +
    • +

      Tags and Variation Selectors Supplement (U+E0000 … U+E0FFF)

      +
      • +
    • +

      Supplementary Private Use Area-A (U+F0000 … U+FFFFF)

      +
      • +
    • +

      Supplementary Private Use Area-B (U+100000 … U+10FFFF)

      +
      • +
    +
    • +
  • +

    All File Names within the same directory MUST be unique following case + normalization as described in section 3.13 of [[!Unicode]].

    +
    • +
  • +

    All File Names within the same directory SHOULD be unique following NFC or NFD + normalization [[!TR15]].

    +
    • +
+ +
+

Some commercial ZIP tools do not support the full Unicode range and might support only the + [[US-ASCII]] range for File Names. Authors who want to + use ZIP tools that have these restrictions might find it is best to restrict their File Names to + the [[US-ASCII]] range. If the names of files cannot be preserved during the unzipping process, + it will be necessary to compensate for any name translation which took place when the files are + referenced by URI from within the content.

+
+ +
+ +
+
+

PWP ZIP Container

+ +
+

Introduction

+ +

An PWP ZIP Container is a physical single-file manifestation of an PWP Abstract + Container.

+ +
+ +
+

ZIP File Requirements

+ +

An PWP ZIP Container uses the ZIP format as specified by [[!ZIP]], but with the following + constraints and clarifications:

+ +
    +
  • +

    The contents of the PWP ZIP Container MUST be a conforming PWP Abstract Container.

    +
    • +
  • +

    PWP ZIP Containers MUST NOT use the features in the ZIP application + note [[!ZIP]] that allow ZIP files to be split across multiple storage media. + PWP Processors MUST treat any PWP files that specify that + the ZIP file is split across multiple storage media as being in error.

    +
    • +
  • +

    PWP ZIP Containers MUST include only stored (uncompressed) and + Deflate-compressed ZIP entries within the ZIP archive. PWP Processors MUST treat any PWP + ZIP Containers that use compression techniques other than Deflate as being in error.

    +
    • +
  • +

    PWP ZIP Containers MAY use the ZIP64 extensions defined as "Version 1" in + section V, subsection G of the ZIP application note [[!ZIP]] and SHOULD use only those + extensions when the content requires them. PWP Processors MUST support the ZIP64 extensions + defined as "Version 1".

    +
    • +
  • +

    PWP ZIP Containers MUST NOT use the encryption features defined by the + ZIP format. PWP Processors MUST treat any PWP ZIP Containers that use encryption techniques + defined by the ZIP format as being in error.

    +
    • +
  • +

    It is not a requirement that PWP Processors preserve information + from an PWP ZIP Container through load and save operations that is not defined within the + PWP Abstract Container; in particular, an PWP Processor does not have to preserve CRC + values, comment fields or fields that hold file system information corresponding to a + particular operating system (e.g., External file attributes and + Extra field).

    +
    • +
  • +

    PWP ZIP Containers MUST encode File System Names using UTF-8 + [[!Unicode]].

    +
    • +
+ +

The following constraints apply to particular fields in the PWP ZIP Container archive:

+ +
    +
  • +

    In the local file header table, PWP ZIP Containers MUST set the + version needed to extract fields to the values + 10, 20 or 45 in order to match the maximum + version level needed by the given file (e.g., 20 if Deflate is needed, + 45 if ZIP64 is needed). PWP Processors MUST treat any other values as being + in error.

    +
    • +
  • +

    In the local file header table, PWP ZIP Containers MUST set the + compression method field to the values 0 or + 8. PWP Processors MUST treat any other values as being in error.

    +
    • +
  • +

    PWP Processors MUST treat PWP ZIP Containers with an Archive + decryption header or an Archive extra data record as being in + error.

    +
    • +
+ +
+ +
+

PWP ZIP Container Media Type Identification

+ +

The PWP ZIP Container MUST contain a manifest.jsonld file. The contents + of this file MUST be conforming to the [[!WEBPUB1]] specification.

+ +
+ +
+ +
+

The application/wpub+zip Media Type

+ +

This appendix registers the media type application/wpub+zip for the Packaged Web Publication + Format (PWP).

+ +

A PWP ZIP Container, or PWP Container, file is a container technology based on the + [[!ZIP]] archive format. It is used to encapsulate Web Publications. PWP and its + related standards are maintained and defined by the World Wide Web Consortium (W3C).

+ +
+
MIME media type name:
+
+

application

+
+
MIME subtype name:
+
+

wpub+zip

+
+
Required parameters:
+
+

None.

+
+
Optional parameters:
+
+

None.

+
+
Encoding considerations:
+
+

PWP ZIP Container files are binary files encoded in the + application/zip media type.

+
+
Security considerations:
+
+

All processors that read PWP ZIP Container files should rigorously check the size and validity of + data retrieved.

+

In addition, because of the various content types that can be embedded in PWP ZIP Container + files, application/wpub+zip may describe content that poses security implications + beyond those noted here. However, only in cases where the processor recognizes and processes the + additional content, or where further processing of that content is dispatched to other + processors, would security issues potentially arise. In such cases, matters of security would + fall outside the domain of this registration document.

+

Security considerations that apply to application/zip also apply to PWP ZIP + Container files.

+
+
Interoperability considerations:
+
+

None.

+
+
Published specification:
+
+

This media type registration is for the Packaged Web Publication Format (PWP), as described by the + Packaged Web Publication Format (PWP) 1.0 specification located at https://github.com/w3c/pwpub/spec/ocf-lite.html.

+
+
Applications that use this media type:
+
+

This media type will soon be in wide use for the distribution of audio and visual publications. + The following list of applications is not exhaustive.

+
    +
  • +
+
+
Additional information:
+
+
+
Magic number(s):
+
+

0: PK 0x03 0x04

+
+
File extension(s):
+
+

PWP ZIP Container files are most often identified with the extension + .pwp.

+
+
Macintosh file type code(s):
+
+

ZIP

+
+
Fragment identifiers:
+
+

None

+
+
+
+
Person & email address to contact for further information:
+
+

public-publ-wg@w3.org

+
+
Intended usage:
+
+

COMMON

+
+
Author/change controller:
+
+

The published specification is a work product of the World Wide Web Consortium (W3C)’s Publishing Working Group. The W3C has change control over this specification.

+
+
+ +
+
+ + From 1a0cbb5c312288fb3aa9f00caa2afa9fc6820c44 Mon Sep 17 00:00:00 2001 From: Laurent Le Meur Date: Sat, 2 Feb 2019 14:26:36 +0100 Subject: [PATCH 2/4] rename to Lightweight Packaging Format - LPF --- spec/ocf-lite.html | 190 +++++++++++++++++++++------------------------ 1 file changed, 90 insertions(+), 100 deletions(-) diff --git a/spec/ocf-lite.html b/spec/ocf-lite.html index 20a3d85..a6c0319 100644 --- a/spec/ocf-lite.html +++ b/spec/ocf-lite.html @@ -2,7 +2,7 @@ - Packaged Web Publication Format (PWP) 1.0 + Lightweight Packaging Format (LPF) 1.0 @@ -16,7 +16,7 @@ wgPublicList: "public-publ-wg", specStatus: "WORKING-DRAFT", noRecTrack: true, - shortName: "ocf-wpub", + shortName: "lpf", prevRecURI: "", edDraftURI: "", copyrightStart: "2018", @@ -28,21 +28,6 @@ } ], formerEditors: [ - { - name: "Garth Conboy", - company: "Google", - companyURL: "https://www.google.com" - }, - { - name: "James Pritchett", - company: "Learning Ally", - companyURL: "https://www.learningally.org/" - }, - { - name: "Markus Gylling", - company: "International Digital Publishing Forum (IDPF)", - companyURL: "https://www.idpf.org" - } ], processVersion: 2018, includePermalinks: true, @@ -61,16 +46,18 @@
-

This specification defines a file format and processing model for encapsulating the set of related resources that comprise a simple Web Publication into a single-file container, the Web Publication Container.

+

This specification defines a file format and processing model for packaging the set of related resources that comprise a Web Publication into a single-file container, the Web Publication Lightweight Package.

-

This specification defines the rules for structuring the file collection in the abstract (the "The specification defines the rules for structuring the file collection in the abstract (the "abstract container") and the rules for the representation of this - abstract container within a ZIP archive (the "ZIP container").

+ abstract container within a ZIP archive (the "ZIP container"), + which is based on a compatible profile of that defined by the Zip Application Note of PKWARE® Inc.

+

Introduction

-

A Web Publication Container is used:

+

A Web Publication Lightweight Package is used:

  • @@ -82,7 +69,7 @@

    Introduction

    sales channel; and

  • -

    to deliver Packaged Web Publications to Reading Systems or users.

    +

    to deliver Packaged Web Publications to User Agents or users.

@@ -100,43 +87,43 @@

Terminology

File Name
-

The name of any type of file within an PWP Abstract Container, whether a directory or +

The name of any type of file within an LPF Abstract Container, whether a directory or a file within a directory.

-
PWP Abstract +
LPF Abstract Container
-

The PWP Abstract Container defines a file system model for the contents of the PWP ZIP Container, as defined in PWP Abstract Container.

+

The LPF Abstract Container defines a file system model for the contents of the LPF ZIP Container, as defined in LPF Abstract Container.

-
PWP Processor
+
LPF Processor
-

A software application that processes PWP ZIP Containers according to the requirements +

A software application that processes LPF ZIP Containers according to the requirements of this specification.

-
PWP ZIP Container
+
LPF ZIP Container

The ZIP-based packaging and distribution format for EPUB Publications, as defined in PWP ZIP Container.

-

PWP ZIP Container and EPUB Container are synonymous.

+ href="#sec-zip-container">LPF ZIP Container.

+

LPF ZIP Container and EPUB Container are synonymous.

Path Name
-

For a given directory within the PWP Abstract +

For a given directory within the LPF Abstract Container, the string holding all directory File Name in the full path concatenated together with a / (U+002F) character separating the directory File Names.

-

For a given file within the PWP Abstract Container, the Path Name is the string holding all +

For a given file within the LPF Abstract Container, the Path Name is the string holding all directory File Names concatenated together with a / character separating the directory File Names, followed by a / character and then the File Name of the file.

Root Directory
-

The root directory represents the base of the PWP Abstract Container file system. This +

The root directory represents the base of the LPF Abstract Container file system. This directory is virtual in nature: a EPUB Reading System might or might not generate a - physical root directory for the contents of the PWP Abstract Container if the contents are + physical root directory for the contents of the LPF Abstract Container if the contents are unzipped.

@@ -146,20 +133,20 @@

Terminology

-

PWP Conformance

+

LPF Conformance

Container Conformance

@@ -168,17 +155,17 @@

Container Conformance

Reading System Conformance

-

An PWP compliant Reading System MUST meet all of the following criteria:

+

An LPF compliant Reading System MUST meet all of the following criteria:

@@ -187,24 +174,24 @@

Reading System Conformance

-

PWP Abstract Container

+

LPF Abstract Container

File and Directory Structure

-

The virtual file system for the PWP Abstract Container MUST have a single common Root +

The virtual file system for the LPF Abstract Container MUST have a single common Root Directory for all of the contents of the container.

-

The PWP Abstract Container MUST include a file named entry.html located into +

The LPF Abstract Container MUST include a file named entry.html located into the Root Directory, which contains the Primary Entry Page of the Web Publication. The Web Publication Manifest MUST NOT be embedded in the Primary Entry Page.

-

The PWP Abstract Container MUST include a file named manifest.jsonld located into +

The LPF Abstract Container MUST include a file named manifest.jsonld located into the Root Directory, which contains the Web Publication Manifest.

Requirements for the contents of both files are described in Web Publication Manifest.

-

All other files within the PWP Abstract Container MAY be in any location descendant from the Root +

All other files within the LPF Abstract Container MAY be in any location descendant from the Root Directory.

@@ -212,7 +199,7 @@

File and Directory Structure

Relative IRIs for Referencing Other Components

-

Files within the PWP Abstract Container MUST reference each other via relative IRI references +

Files within the LPF Abstract Container MUST reference each other via relative IRI references ([[!RFC3987]] and [[!RFC3986]]).

@@ -259,16 +246,15 @@

Relative IRIs for Referencing Other Components

File Names

-

This section is identical to its sibling in [[!OCF32]].

+

This section is identical to its [[!OCF32]] counterpart.

-

The File Name restrictions described in this section are designed to allow Path Names and File Names to be used without modification on most commonly used operating systems. This - specification does not specify how an PWP Processor that is unable to represent PWP File and + specification does not specify how an LPF Processor that is unable to represent LPF File and Path Names would compensate for this incompatibility.

-

In the context of an PWP Abstract Container, File and Path Names are case +

In the context of an LPF Abstract Container, File and Path Names are case sensitive and MUST meet all of the following criteria:

    @@ -279,7 +265,7 @@

    File Names

    File Names MUST NOT exceed 255 bytes.

  • -

    The Path Name for any directory or file within the PWP Abstract Container +

    The Path Name for any directory or file within the LPF Abstract Container MUST NOT exceed 65535 bytes.

  • @@ -365,12 +351,12 @@

    File Names

-

PWP ZIP Container

+

LPF ZIP Container

Introduction

-

An PWP ZIP Container is a physical single-file manifestation of an PWP Abstract +

An LPF ZIP Container is a physical single-file manifestation of an LPF Abstract Container.

@@ -378,68 +364,73 @@

Introduction

ZIP File Requirements

-

An PWP ZIP Container uses the ZIP format as specified by [[!ZIP]], but with the following +

+

This section is totally compatible with its [[!OCF32]] counterpart.

+
+ + +

An LPF ZIP Container uses the ZIP format as specified by [[!ZIP]], but with the following constraints and clarifications:

  • -

    The contents of the PWP ZIP Container MUST be a conforming PWP Abstract Container.

    +

    The contents of the LPF ZIP Container MUST be a conforming LPF Abstract Container.

  • -

    PWP ZIP Containers MUST NOT use the features in the ZIP application +

    LPF ZIP Containers MUST NOT use the features in the ZIP application note [[!ZIP]] that allow ZIP files to be split across multiple storage media. - PWP Processors MUST treat any PWP files that specify that + LPF Processors MUST treat any LPF files that specify that the ZIP file is split across multiple storage media as being in error.

  • -

    PWP ZIP Containers MUST include only stored (uncompressed) and - Deflate-compressed ZIP entries within the ZIP archive. PWP Processors MUST treat any PWP +

    LPF ZIP Containers MUST include only stored (uncompressed) and + Deflate-compressed ZIP entries within the ZIP archive. LPF Processors MUST treat any LPF ZIP Containers that use compression techniques other than Deflate as being in error.

  • -

    PWP ZIP Containers MAY use the ZIP64 extensions defined as "Version 1" in +

    LPF ZIP Containers MAY use the ZIP64 extensions defined as "Version 1" in section V, subsection G of the ZIP application note [[!ZIP]] and SHOULD use only those - extensions when the content requires them. PWP Processors MUST support the ZIP64 extensions + extensions when the content requires them. LPF Processors MUST support the ZIP64 extensions defined as "Version 1".

  • -

    PWP ZIP Containers MUST NOT use the encryption features defined by the - ZIP format. PWP Processors MUST treat any PWP ZIP Containers that use encryption techniques - defined by the ZIP format as being in error.

    +

    LPF ZIP Containers MUST NOT use the encryption feature defined by the + ZIP application note. LPF Processors MUST treat any LPF ZIP Containers that + use encryption techniques defined by the ZIP format as being in error.

  • -

    It is not a requirement that PWP Processors preserve information - from an PWP ZIP Container through load and save operations that is not defined within the - PWP Abstract Container; in particular, an PWP Processor does not have to preserve CRC +

    It is not a requirement that LPF Processors preserve information + from an LPF ZIP Container through load and save operations that is not defined within the + LPF Abstract Container; in particular, an LPF Processor does not have to preserve CRC values, comment fields or fields that hold file system information corresponding to a particular operating system (e.g., External file attributes and Extra field).

  • -

    PWP ZIP Containers MUST encode File System Names using UTF-8 +

    LPF ZIP Containers MUST encode File System Names using UTF-8 [[!Unicode]].

-

The following constraints apply to particular fields in the PWP ZIP Container archive:

+

The following constraints apply to particular fields in the LPF ZIP Container archive:

  • -

    In the local file header table, PWP ZIP Containers MUST set the +

    In the local file header table, LPF ZIP Containers MUST set the version needed to extract fields to the values 10, 20 or 45 in order to match the maximum version level needed by the given file (e.g., 20 if Deflate is needed, - 45 if ZIP64 is needed). PWP Processors MUST treat any other values as being + 45 if ZIP64 is needed). LPF Processors MUST treat any other values as being in error.

  • -

    In the local file header table, PWP ZIP Containers MUST set the +

    In the local file header table, LPF ZIP Containers MUST set the compression method field to the values 0 or - 8. PWP Processors MUST treat any other values as being in error.

    + 8. LPF Processors MUST treat any other values as being in error.

  • -

    PWP Processors MUST treat PWP ZIP Containers with an Archive +

    LPF Processors MUST treat LPF ZIP Containers with an Archive decryption header or an Archive extra data record as being in error.

    • @@ -448,9 +439,9 @@

    ZIP File Requirements

-

PWP ZIP Container Media Type Identification

+

LPF ZIP Container Media Type Identification

-

The PWP ZIP Container MUST contain a manifest.jsonld file. The contents +

The LPF ZIP Container MUST contain a manifest.jsonld file. The contents of this file MUST be conforming to the [[!WEBPUB1]] specification.

@@ -460,11 +451,10 @@

PWP ZIP Container Media Type Identification

The application/wpub+zip Media Type

-

This appendix registers the media type application/wpub+zip for the Packaged Web Publication - Format (PWP).

+

This appendix registers the media type application/wpub+zip for the Lightweight Packaging Format (LPF).

-

A PWP ZIP Container, or PWP Container, file is a container technology based on the - [[!ZIP]] archive format. It is used to encapsulate Web Publications. PWP and its +

A LPF ZIP Container file is a container technology based on the + [[!ZIP]] archive format. It is used to encapsulate Web Publications. LPF and its related standards are maintained and defined by the World Wide Web Consortium (W3C).

@@ -486,21 +476,21 @@

The application/wpub+zip Media Type

Encoding considerations:
-

PWP ZIP Container files are binary files encoded in the LPF ZIP Container files are binary files encoded in the application/zip media type.

Security considerations:
-

All processors that read PWP ZIP Container files should rigorously check the size and validity of +

All processors that read LPF ZIP Container files should rigorously check the size and validity of data retrieved.

-

In addition, because of the various content types that can be embedded in PWP ZIP Container +

In addition, because of the various content types that can be embedded in LPF ZIP Container files, application/wpub+zip may describe content that poses security implications beyond those noted here. However, only in cases where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues potentially arise. In such cases, matters of security would fall outside the domain of this registration document.

-

Security considerations that apply to application/zip also apply to PWP ZIP +

Security considerations that apply to application/zip also apply to LPF ZIP Container files.

Interoperability considerations:
@@ -509,10 +499,10 @@

The application/wpub+zip Media Type

Published specification:
-

This media type registration is for the Packaged Web Publication Format (PWP), as described by the - Packaged Web Publication Format (PWP) 1.0 specification located at https://github.com/w3c/pwpub/spec/ocf-lite.html.

+

This media type registration is for the Lightweight Packaging Format (LPF), as described by the + Lightweight Packaging Format (LPF) 1.0 specification located at https://github.com/w3c/LPFub/spec/ocf-lite.html.

Applications that use this media type:
@@ -531,8 +521,8 @@

The application/wpub+zip Media Type

File extension(s):
-

PWP ZIP Container files are most often identified with the extension - .pwp.

+

LPF ZIP Container files are most often identified with the extension + .LPF.

Macintosh file type code(s):
From b3fe9881043c659c019067a640d78e96ed4faf71 Mon Sep 17 00:00:00 2001 From: Laurent Le Meur Date: Sun, 3 Feb 2019 10:55:53 +0100 Subject: [PATCH 3/4] Complete re-structuration --- spec/ocf-lite.html | 471 ++++++++++++--------------------------------- 1 file changed, 127 insertions(+), 344 deletions(-) diff --git a/spec/ocf-lite.html b/spec/ocf-lite.html index a6c0319..a616440 100644 --- a/spec/ocf-lite.html +++ b/spec/ocf-lite.html @@ -47,29 +47,23 @@

This specification defines a file format and processing model for packaging the set of related resources that comprise a Web Publication into a single-file container, the Web Publication Lightweight Package.

- -

The specification defines the rules for structuring the file collection in the abstract (the "abstract container") and the rules for the representation of this - abstract container within a ZIP archive (the "ZIP container"), - which is based on a compatible profile of that defined by the Zip Application Note of PKWARE® Inc.

-
-
+

Introduction

A Web Publication Lightweight Package is used:

  • -

    to exchange in-progress Packaged Web Publications between different individuals and/or +

    to exchange in-progress packaged Web Publications between different individuals and/or different organizations;

  • -

    to provide Packaged Web Publications from a publisher or conversion house to the distribution or +

    to provide packaged Web Publications from a publisher or conversion house to the distribution or sales channel; and

  • -

    to deliver Packaged Web Publications to User Agents or users.

    +

    to deliver packaged Web Publications to users or User Agents.

@@ -87,365 +81,155 @@

Terminology

File Name
-

The name of any type of file within an LPF Abstract Container, whether a directory or - a file within a directory.

+

The name of any type of file or directory within a Web Publication Lightweight Package.

-
LPF Abstract - Container
+
File Path
-

The LPF Abstract Container defines a file system model for the contents of the LPF ZIP Container, as defined in LPF Abstract Container.

+

The position of a file or directory within a Web Publication Lightweight Package, + represented as string of characters in which path components, + separated by the delimiting character / (U+002F), + represent each directory.

LPF Processor
-

A software application that processes LPF ZIP Containers according to the requirements +

A software application that processes Web Publication Lightweight Packages according to the requirements of this specification.

-
LPF ZIP Container
+
Package
-

The ZIP-based packaging and distribution format for EPUB Publications, as defined in LPF ZIP Container.

-

LPF ZIP Container and EPUB Container are synonymous.

+

In this specification, alias to Web Publication Lightweight Package.

-
Path Name
+
Primary Entry Page
-

For a given directory within the LPF Abstract - Container, the string holding all directory File Name in the full path - concatenated together with a / (U+002F) character separating the - directory File Names.

-

For a given file within the LPF Abstract Container, the Path Name is the string holding all - directory File Names concatenated together with a / character separating the - directory File Names, followed by a / character and then the File Name of the - file.

+

(see def in the Web Publication specification).

Root Directory
-

The root directory represents the base of the LPF Abstract Container file system. This - directory is virtual in nature: a EPUB Reading System might or might not generate a - physical root directory for the contents of the LPF Abstract Container if the contents are - unzipped.

+

The base of the Package file system. + This directory is virtual in nature: an LPF Processor might or might + not generate a physical root directory for the contents of the + Package if the contents are unzipped.

+
+
User Agent
+
+

A User Agent ...

+
+
Web Publication
+
+

A Web Publication ...

+
+
Web Publication Manifest
+
+

(see def in the Web Publication specification).

-
-
-
-

LPF Conformance

-
-

Container Conformance

+
+

Specification

-
    -
  • -

    An LPF Abstract Container MUST meet the conformance - constraints defined in LPF Abstract - Container.

    -
    • -
  • -

    An LPF ZIP Container MUST meet the conformance constraints - defined in LPF ZIP Container.

    -
    • -
- -
+
-
-

Reading System Conformance

+

ZIP File Requirements

-

An LPF compliant Reading System MUST meet all of the following criteria:

- -
    -
  • -

    It MUST process the LPF ZIP Container in conformance with all Reading - System conformance constraints expressed in LPF ZIP - Container.

    -
    • -
  • -

    It MUST process the LPF Abstract Container in conformance with all Reading - System conformance constraints expressed in LPF Abstract - Container.

    -
    • -
+

A Web Publication Lightweight Package uses the ZIP format as specified in ISO/IEC 21320-1:2015 ([[!ZIP]]).

-
-
-

LPF Abstract Container

- -
-

File and Directory Structure

- -

The virtual file system for the LPF Abstract Container MUST have a single common Root - Directory for all of the contents of the container.

- -

The LPF Abstract Container MUST include a file named entry.html located into - the Root Directory, which contains the Primary Entry Page of the Web Publication. The Web Publication Manifest MUST NOT be embedded in the Primary Entry Page.

+
+ +

File and Directory Structure

-

The LPF Abstract Container MUST include a file named manifest.jsonld located into - the Root Directory, which contains the Web Publication Manifest.

- -

Requirements for the contents of both files are described - in Web Publication Manifest.

+

A Package MUST include at least one of the following files + in its Root Directory:

+ + + +

The contents of both files are specified in [[!WEBPUB]].

-

All other files within the LPF Abstract Container MAY be in any location descendant from the Root - Directory. +

If both entry.html and manifest.jsonld are present in the package, + the former MUST contain a reference to the latter.

+

All other files within the Package MAY be in any location + descendant from the Root Directory.

+
- +
-

Relative IRIs for Referencing Other Components

- -

Files within the LPF Abstract Container MUST reference each other via relative IRI references - ([[!RFC3987]] and [[!RFC3986]]).

- - - -

For relative IRI references, the Base IRI [[!RFC3986]] is determined by the relevant language - specifications for the given file formats. For example, CSS defines how relative IRI references work - in the context of CSS style sheets and property declarations [[!CSSSnapshot]].

- -
-

Some language specifications reference Requests For Comments [[RFC]] that preceded [[RFC3987]], - in which case the earlier RFC applies for content in that particular language.

-
- -

For instance, the Base IRIs expressed within the manifest.jsonld - file use the Root Directory of the LPF Abstract Container as the default Base IRI.

- - - -

then the path illustrations/datatypes.svg is relative to the root directory for the LPF - Abstract Container. - -

All relative IRI references MUST resolve to resources within the LPF Abstract Container (i.e. at or - below the Root Directory).

- -
- -
-

File Names

- -
-

This section is identical to its [[!OCF32]] counterpart.

-
- -

The File Name restrictions described in this section are designed to allow Path Names - and File Names to be used without modification on most commonly used operating systems. This - specification does not specify how an LPF Processor that is unable to represent LPF File and - Path Names would compensate for this incompatibility.

- -

In the context of an LPF Abstract Container, File and Path Names are case - sensitive and MUST meet all of the following criteria:

- -
    -
  • -

    File Names MUST be UTF-8 [[!Unicode]] encoded.

    -
    • -
  • -

    File Names MUST NOT exceed 255 bytes.

    -
    • -
  • -

    The Path Name for any directory or file within the LPF Abstract Container - MUST NOT exceed 65535 bytes.

    -
    • -
  • -

    File Names MUST NOT use the following [[!Unicode]] characters, as these - characters might not be supported consistently across commonly-used operating systems:

    -
      -
    • -

      SOLIDUS: / (U+002F)

      -
      • -
    • -

      QUOTATION MARK: " (U+0022)

      -
      • -
    • -

      ASTERISK: * (U+002A)

      -
      • -
    • -

      FULL STOP as the last character: . (U+002E)

      -
      • -
    • -

      COLON: : (U+003A)

      -
      • -
    • -

      LESS-THAN SIGN: < (U+003C)

      -
      • -
    • -

      GREATER-THAN SIGN: > (U+003E)

      -
      • -
    • -

      QUESTION MARK: ? (U+003F)

      -
      • -
    • -

      REVERSE SOLIDUS: \ (U+005C)

      -
      • -
    • -

      DEL (U+007F)

      -
      • -
    • -

      C0 range (U+0000 … U+001F)

      -
      • -
    • -

      C1 range (U+0080 … U+009F)

      -
      • -
    • -

      Private Use Area (U+E000 … U+F8FF)

      -
      • -
    • -

      Non characters in Arabic Presentation Forms-A (U+FDDO … U+FDEF)

      -
      • -
    • -

      Specials (U+FFF0 … U+FFFF)

      -
      • -
    • -

      Tags and Variation Selectors Supplement (U+E0000 … U+E0FFF)

      -
      • -
    • -

      Supplementary Private Use Area-A (U+F0000 … U+FFFFF)

      -
      • -
    • -

      Supplementary Private Use Area-B (U+100000 … U+10FFFF)

      -
      • -
    -
    • -
  • -

    All File Names within the same directory MUST be unique following case - normalization as described in section 3.13 of [[!Unicode]].

    -
    • -
  • -

    All File Names within the same directory SHOULD be unique following NFC or NFD - normalization [[!TR15]].

    -
    • -
- -
-

Some commercial ZIP tools do not support the full Unicode range and might support only the - [[US-ASCII]] range for File Names. Authors who want to - use ZIP tools that have these restrictions might find it is best to restrict their File Names to - the [[US-ASCII]] range. If the names of files cannot be preserved during the unzipping process, - it will be necessary to compensate for any name translation which took place when the files are - referenced by URI from within the content.

-
+

Relative IRIs for Referencing Other Components

+ +

Files within the Package MUST reference each other via relative IRI references, + as specified in [[!RFC3987]].

+ +
+

Some language specifications reference Requests For Comments [[RFC]] that preceded [[RFC3987]], + in which case the earlier RFC applies for content in that particular language.

+
+ +

All relative IRI references MUST resolve to resources within the Package (i.e. at or + below the Root Directory).

+ +
+

The [[!ZIP]] specification has few constraints on the characters allowed for file and dirctory names. + When crafting such names, authors must be careful to use characters which + allow a broad interoperability among operating systems and are compatible with relative IRI references.

+
+ + + +

For relative IRI references, the Base URI [[!RFC3986]] is determined by the relevant language + specifications for the given file formats.

+ +
+

For example, CSS defines how relative IRI references work + in the context of CSS style sheets and property declarations [[!CSSSnapshot]].

+
+ +

The Base URIs expressed within the manifest.jsonld + file use the Root Directory of the Package as the default Base URI.

+ + +
- +
-
-

LPF ZIP Container

- -
-

Introduction

- -

An LPF ZIP Container is a physical single-file manifestation of an LPF Abstract - Container.

- -
- -
-

ZIP File Requirements

-
-

This section is totally compatible with its [[!OCF32]] counterpart.

-
+
+

User Agent Conformance

+

An LPF compliant User Agent MUST meet all of the following criteria:

-

An LPF ZIP Container uses the ZIP format as specified by [[!ZIP]], but with the following - constraints and clarifications:

- -
    -
  • -

    The contents of the LPF ZIP Container MUST be a conforming LPF Abstract Container.

    -
    • -
  • -

    LPF ZIP Containers MUST NOT use the features in the ZIP application - note [[!ZIP]] that allow ZIP files to be split across multiple storage media. - LPF Processors MUST treat any LPF files that specify that - the ZIP file is split across multiple storage media as being in error.

    -
    • -
  • -

    LPF ZIP Containers MUST include only stored (uncompressed) and - Deflate-compressed ZIP entries within the ZIP archive. LPF Processors MUST treat any LPF - ZIP Containers that use compression techniques other than Deflate as being in error.

    -
    • -
  • -

    LPF ZIP Containers MAY use the ZIP64 extensions defined as "Version 1" in - section V, subsection G of the ZIP application note [[!ZIP]] and SHOULD use only those - extensions when the content requires them. LPF Processors MUST support the ZIP64 extensions - defined as "Version 1".

    -
    • -
  • -

    LPF ZIP Containers MUST NOT use the encryption feature defined by the - ZIP application note. LPF Processors MUST treat any LPF ZIP Containers that - use encryption techniques defined by the ZIP format as being in error.

    -
    • -
  • -

    It is not a requirement that LPF Processors preserve information - from an LPF ZIP Container through load and save operations that is not defined within the - LPF Abstract Container; in particular, an LPF Processor does not have to preserve CRC - values, comment fields or fields that hold file system information corresponding to a - particular operating system (e.g., External file attributes and - Extra field).

    -
    • -
  • -

    LPF ZIP Containers MUST encode File System Names using UTF-8 - [[!Unicode]].

    -
    • -
- -

The following constraints apply to particular fields in the LPF ZIP Container archive:

- -
    -
  • -

    In the local file header table, LPF ZIP Containers MUST set the - version needed to extract fields to the values - 10, 20 or 45 in order to match the maximum - version level needed by the given file (e.g., 20 if Deflate is needed, - 45 if ZIP64 is needed). LPF Processors MUST treat any other values as being - in error.

    -
    • -
  • -

    In the local file header table, LPF ZIP Containers MUST set the - compression method field to the values 0 or - 8. LPF Processors MUST treat any other values as being in error.

    -
    • -
  • -

    LPF Processors MUST treat LPF ZIP Containers with an Archive - decryption header or an Archive extra data record as being in - error.

    -
    • -
- -
- -
-

LPF ZIP Container Media Type Identification

- -

The LPF ZIP Container MUST contain a manifest.jsonld file. The contents - of this file MUST be conforming to the [[!WEBPUB1]] specification.

- -
- +
    +
  • +
    • +
  • +
    • +
@@ -453,9 +237,9 @@

The application/wpub+zip Media Type

This appendix registers the media type application/wpub+zip for the Lightweight Packaging Format (LPF).

-

A LPF ZIP Container file is a container technology based on the - [[!ZIP]] archive format. It is used to encapsulate Web Publications. LPF and its - related standards are maintained and defined by the World Wide Web Consortium (W3C).

+

A Lightweight Packaging Format (or LPF) file is a container technology based on the + [[!ZIP]] archive format. It is used to encapsulate Web Publications. + LPF and its related standards are maintained and defined by the World Wide Web Consortium (W3C).

MIME media type name:
@@ -476,22 +260,21 @@

The application/wpub+zip Media Type

Encoding considerations:
-

LPF ZIP Container files are binary files encoded in the LPF files are binary files encoded in the application/zip media type.

Security considerations:
-

All processors that read LPF ZIP Container files should rigorously check the size and validity of +

All processors that read LPF files should rigorously check the size and validity of data retrieved.

-

In addition, because of the various content types that can be embedded in LPF ZIP Container - files, application/wpub+zip may describe content that poses security implications +

In addition, because of the various content types that can be embedded in LPF files + , application/wpub+zip may describe content that poses security implications beyond those noted here. However, only in cases where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues potentially arise. In such cases, matters of security would fall outside the domain of this registration document.

-

Security considerations that apply to application/zip also apply to LPF ZIP - Container files.

+

Security considerations that apply to application/zip also apply to LPF files.

Interoperability considerations:
@@ -521,8 +304,8 @@

The application/wpub+zip Media Type

File extension(s):
-

LPF ZIP Container files are most often identified with the extension - .LPF.

+

LPF files are most often identified with the extension + .lpf.

Macintosh file type code(s):
From 660a7b4d23beeeb1de799c4cf9e5e9f2f4789119 Mon Sep 17 00:00:00 2001 From: Laurent Le Meur Date: Mon, 11 Feb 2019 18:59:50 +0100 Subject: [PATCH 4/4] take into account Ivan's last comments --- spec/ocf-lite.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/spec/ocf-lite.html b/spec/ocf-lite.html index a616440..c3abfaa 100644 --- a/spec/ocf-lite.html +++ b/spec/ocf-lite.html @@ -155,7 +155,7 @@

File and Directory Structure

The contents of both files are specified in [[!WEBPUB]].

If both entry.html and manifest.jsonld are present in the package, - the former MUST contain a reference to the latter.

+ the former MUST contain a reference to the latter, following the rules described by the definition of the PEP

All other files within the Package MAY be in any location descendant from the Root Directory.

@@ -319,7 +319,7 @@

The application/wpub+zip Media Type

Person & email address to contact for further information:
-

public-publ-wg@w3.org

+

ivan@w3.org

Intended usage: