Recent changes to binary-data-catalogue

binary-data-catalogue modified by Wolfgang Keller

Wolfgang Keller — Mon, 09 Jan 2017 16:00:35 -0000

binary-data-catalogue modified by Wolfgang Keller

Wolfgang Keller — Thu, 03 Nov 2016 07:25:43 -0000

--- v18
+++ v19
@@ -4,7 +4,7 @@
 This format, stored in record field 66, was introduced with  *JPasswords* 0-8-0 and follows the guidelines of the IFF data format definition by *Electronic Arts*. JPWS does not seek data interchange on field 66 but this may change in the future. The language used for the definition is a variant of the [Backus-Naur-Form](https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form) , the JPWS [Data-Definition-Language](data-definition-language). The following definition breaks down the data format into character literals and a presupposed understanding of "<byte>" as atomic 8-bit data constituent.

     <catalog> := 'CAT ' <length> {<FORM-element>}
-    <FORM-element> := <raer> | <comp>
+    <FORM-element> := <rear> | <comp>
     <comp> := 'FORM' <length> 'COMP' [<ZIP-data>]
     <rear> := 'FORM' <length> 'REAR' {<rear-chunk>}

binary-data-catalogue modified by Wolfgang Keller

Wolfgang Keller — Wed, 21 Sep 2016 21:39:28 -0000

--- v17
+++ v18
@@ -22,7 +22,7 @@
 ---------------------------
 Annotations + Semantic Rules:

-1. <byte> : the bit-order of a Byte is unspecified by this format definition. In the regular case, the bit-order does not require attention on the programming level of computer systems.
+1. <byte> : the bit-order of a Byte is unspecified by this format definition. The bit-order normally does not require attention on the program level of computer systems.
 2. <length> : a 4 byte signed integer value in BIG-ENDIAN byte order (most significant first)
 + <catalog>    : <length> denotes length in bytes of <catalog> minus 8.
 + <comp>   : compressed FORM data; <length> denotes length in bytes of <comp> minus 8;

binary-data-catalogue modified by Wolfgang Keller

Wolfgang Keller — Wed, 21 Sep 2016 21:33:59 -0000

--- v16
+++ v17
@@ -1,7 +1,7 @@
-### Record Data Field 66
+### JPWS Binary Data Catalog

 JPWS Binary Data Catalog, Version 1.2, Description (12.09.2016)
-This format for record field 66 was introduced with  *JPasswords* 0-8-0 and follows the guidelines of the IFF data format definition by Electronic Arts. JPWS does not seek data interchange on field 66 but this may change in the future. The language used for the definition is a variant of the [Backus-Naur-Form](https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form) , the JPWS [Data-Definition-Language](data-definition-language). The following definition breaks down the data format into character literals and a presupposed understanding of "<byte>" as atomic 8-bit data constituent.
+This format, stored in record field 66, was introduced with  *JPasswords* 0-8-0 and follows the guidelines of the IFF data format definition by *Electronic Arts*. JPWS does not seek data interchange on field 66 but this may change in the future. The language used for the definition is a variant of the [Backus-Naur-Form](https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form) , the JPWS [Data-Definition-Language](data-definition-language). The following definition breaks down the data format into character literals and a presupposed understanding of "<byte>" as atomic 8-bit data constituent.

     <catalog> := 'CAT ' <length> {<FORM-element>}
     <FORM-element> := <raer> | <comp>

format-record-field-66 modified by Wolfgang Keller

Wolfgang Keller — Mon, 19 Sep 2016 21:28:28 -0000

--- v14
+++ v15
@@ -22,18 +22,19 @@
 ---------------------------
 Annotations + Semantic Rules:

-1. <length> : a 4 byte signed integer value in BIG-ENDIAN order (most significant byte first)
-+ <catalog>    : <length> denotes length in bytes for <catalog> minus 8.
+1. <byte> : the bit-order of a Byte is unspecified by this format definition. In the regular case, the bit-order does not require attention on the programming level of computer systems.
+2. <length> : a 4 byte signed integer value in BIG-ENDIAN byte order (most significant first)
++ <catalog>    : <length> denotes length in bytes of <catalog> minus 8.
 + <comp>   : compressed FORM data; <length> denotes length in bytes of <comp> minus 8; 
                         length of <ZIP-data> == <length> minus 4. 
-+ <ZIP-data> : contains a <FORM-element> in a standard ZIP compression.
++ <ZIP-data> : contains standard ZIP compression data translated from a <FORM-element>.
 + <rear>   : record archive data, a collection of archive-chunks; <length> denotes length in 
                         bytes of <rear> minus 8.
 + <rear-chunk>: <length> denotes length in bytes of <rear-chunk> minus 8; <chunk-name>
                         may appear only once with type PROP and only once within all other types.
-+ <chunk-type> : 'PTEX' = plain text, 'PROP' = properties map (text), 'BLOB' = binary large object, 'JPEG' = JPEG image data, 'SCPT' = properties map (text) as a  document script.
-+ <chunk-name>: the chunk name has to be unique for a data entry in the catalogue; it is recommended to use random byte values. A data entry  can have two parts in the catalogue: PROP and one of the rest of the types. This is saying that PROP is an additional type to any occurring other data type; it represents a Properties map (text) related to a data entry. There is no formal rule about the conjunction of both parts, i.e. any one can stand alone although an alone-standing PROP does not define or declare a typed data entry and hence may be ignored in a reading interface. The type SCPT is a properties map by itself and does not relate to a PROP entry, hence a PROP entry related to a SCPT is correct but meaningless.
-+ <chunk-data>: for the types PROP, PTEX and SCPT this is an UTF-8 serialisation of a text string;
++ <chunk-type> : 'PTEX' = plain text, 'PROP' = properties map (text), 'BLOB' = binary large object, 'JPEG' = JPEG image data, 'UNIT' = properties map (text) as a  document script.
++ <chunk-name>: the chunk name has to be unique for a data entry in the catalogue; it is recommended to use random byte values. A data entry  can have two parts in the catalogue: PROP and one of the rest of the types. This is saying that PROP is an additional type to any occurring other data type; it represents a Properties map (text) related to a data entry. There is no formal rule about the conjunction of both parts, i.e. any one can stand alone although an alone-standing PROP does not define or declare a typed data entry and hence may be ignored in a reading interface. The type UNIT is a properties map by itself and does not relate to a PROP entry, hence a PROP entry related to a UNIT is correct but meaningless.
++ <chunk-data>: for the types PROP, PTEX and UNIT this is an UTF-8 serialisation of a text string;
      for type JPEG this is a valid JPEG compressed image format; for BLOB this is a format free block of binary data (opaque).

 ---------------------------

format-record-field-66 modified by Wolfgang Keller

Wolfgang Keller — Mon, 12 Sep 2016 10:45:00 -0000

--- v13
+++ v14
@@ -1,7 +1,7 @@
 ### Record Data Field 66

-JPWS Binary Data Catalog, Version 1.1, Description (20.08.2016)
-This format for record field 66 is introduced with  *JPasswords* 0-8-0 and follows the guidelines of the IFF data format definition by Electronic Arts. JPWS does not seek data interchange on field 66 but this may change in the future. The language used for the definition is a variant of the [Backus-Naur-Form](https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form) , the JPWS [Data-Definition-Language](data-definition-language).
+JPWS Binary Data Catalog, Version 1.2, Description (12.09.2016)
+This format for record field 66 was introduced with  *JPasswords* 0-8-0 and follows the guidelines of the IFF data format definition by Electronic Arts. JPWS does not seek data interchange on field 66 but this may change in the future. The language used for the definition is a variant of the [Backus-Naur-Form](https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form) , the JPWS [Data-Definition-Language](data-definition-language). The following definition breaks down the data format into character literals and a presupposed understanding of "<byte>" as atomic 8-bit data constituent.

     <catalog> := 'CAT ' <length> {<FORM-element>}
     <FORM-element> := <raer> | <comp>
@@ -9,7 +9,7 @@
     <rear> := 'FORM' <length> 'REAR' {<rear-chunk>}

     <rear-chunk> := <chunk-type> <length> <chunk-name> [<chunk-data>]
-    <chunk-type> := 'PROP' | 'PTEX' | 'BLOB' | 'JPEG' | 'SCPT'
+    <chunk-type> := 'PROP' | 'PTEX' | 'BLOB' | 'JPEG' | 'UNIT'
     <chunk-name> := <byte>:4 -- random binary
     <chunk-data> := <binary-data>

format-record-field-66 modified by Wolfgang Keller

Wolfgang Keller — Sat, 27 Aug 2016 20:08:52 -0000

format-record-field-66 modified by Wolfgang Keller

Wolfgang Keller — Sat, 27 Aug 2016 19:44:14 -0000

--- v11
+++ v12
@@ -1,41 +1,40 @@
 ### Record Data Field 66

 JPWS Binary Data Catalog, Version 1.1, Description (20.08.2016)
-This format for record field 66 is introduced with  *JPasswords* 0-8-0 and follows the guidelines of the IFF data format definition by Electronic Arts. JPWS does not seek data interchange on field 66 but this may change in the future. The language used for the definition is a variant of the [Bachus-Naur-Form](https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form) , the JPWS [Data-Definition-Language](data-definition-language).
+This format for record field 66 is introduced with  *JPasswords* 0-8-0 and follows the guidelines of the IFF data format definition by Electronic Arts. JPWS does not seek data interchange on field 66 but this may change in the future. The language used for the definition is a variant of the [Backus-Naur-Form](https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form) , the JPWS [Data-Definition-Language](data-definition-language).

-    <catalog> := 'CAT ' <length> <FORM-element>:n
+    <catalog> := 'CAT ' <length> {<FORM-element>}
     <FORM-element> := <raer> | <comp>
-    <comp> := 'FORM' <length> 'COMP' <ZIP-data>
-    <rear> := 'FORM' <length> 'REAR' <rear-chunk>:n
+    <comp> := 'FORM' <length> 'COMP' [<ZIP-data>]
+    <rear> := 'FORM' <length> 'REAR' {<rear-chunk>}

     <rear-chunk> := <chunk-type> <length> <chunk-name> [<chunk-data>]
     <chunk-type> := 'PROP' | 'PTEX' | 'BLOB' | 'JPEG' | 'SCPT'
-    <chunk-name> := 4 bytes random binary
+    <chunk-name> := <byte>:4 -- random binary
     <chunk-data> := <binary-data>

-    <length> := 4-byte signed integer in BIG-ENDIAN (MSB first)
+    <length> := <byte>:4 -- signed integer in BIG-ENDIAN (MSB first)
     <ZIP-data> := <binary-data>
-    <binary-data> := byte:n
+    <binary-data> := {<byte>}

 ---------------------------
-Annotations + Rules:
+Annotations + Semantic Rules:

-1. 'n' : stands for an integer value from {0..MI} in all definitions; MI = (2^31)-1 = 2147483647.
+1. <length> : a 4 byte signed integer value in BIG-ENDIAN order (most significant byte first)
 + <catalog>    : <length> denotes length in bytes for <catalog> minus 8.
 + <comp>   : compressed FORM data; <length> denotes length in bytes of <comp> minus 8; 
-                        length of <ZIP-data> = <length> minus 4. 
+                        length of <ZIP-data> == <length> minus 4. 
 + <ZIP-data> : contains a <FORM-element> in a standard ZIP compression.
 + <rear>   : record archive data, a collection of archive-chunks; <length> denotes length in 
                         bytes of <rear> minus 8.
-+ <rear-chunk>: <length> denotes length in bytes for <rear-chunk> minus 8; <chunk-name>
++ <rear-chunk>: <length> denotes length in bytes of <rear-chunk> minus 8; <chunk-name>
                         may appear only once with type PROP and only once within all other types.
 + <chunk-type> : 'PTEX' = plain text, 'PROP' = properties map (text), 'BLOB' = binary large object, 'JPEG' = JPEG image data, 'SCPT' = properties map (text) as a  document script.
-+ <chunk-name>: the chunk name has to be unique for a data entry in the catalogue. A data entry  can have two parts in the catalogue: PROP and one of the rest of the types. This is saying that PROP is an additional type to any occurring other data type; it represents a Properties map (text) related to a data entry. There is no formal rule about the conjunction of both parts, i.e. any one can stand alone although an alone-standing PROP does not define or declare a typed data entry and hence may be ignored in a reading interface. The type SCPT is a properties map by itself and does not relate to a PROP entry, hence a PROP entry related to a SCPT is correct but meaningless.
++ <chunk-name>: the chunk name has to be unique for a data entry in the catalogue; it is recommended to use random byte values. A data entry  can have two parts in the catalogue: PROP and one of the rest of the types. This is saying that PROP is an additional type to any occurring other data type; it represents a Properties map (text) related to a data entry. There is no formal rule about the conjunction of both parts, i.e. any one can stand alone although an alone-standing PROP does not define or declare a typed data entry and hence may be ignored in a reading interface. The type SCPT is a properties map by itself and does not relate to a PROP entry, hence a PROP entry related to a SCPT is correct but meaningless.
 + <chunk-data>: for the types PROP, PTEX and SCPT this is an UTF-8 serialisation of a text string;
-                         for type JPEG this is a valid JPEG compressed image format; for BLOB this is a 
-                         format free block of binary data (opaque).
+     for type JPEG this is a valid JPEG compressed image format; for BLOB this is a format free block of binary data (opaque).

 ---------------------------
 Sources: IFF Format (Electronic Arts), https://en.wikipedia.org/wiki/Interchange_File_Format

format-record-field-66 modified by Wolfgang Keller

Wolfgang Keller — Tue, 23 Aug 2016 11:19:23 -0000

--- v10
+++ v11
@@ -1,7 +1,7 @@
 ### Record Data Field 66

 JPWS Binary Data Catalog, Version 1.1, Description (20.08.2016)
-This format for record field 66 is introduced with  *JPasswords* 0-8-0 and follows the guidelines of the IFF data format definition by Electronic Arts. JPWS does not seek data interchange on field 66 but this may change in the future.
+This format for record field 66 is introduced with  *JPasswords* 0-8-0 and follows the guidelines of the IFF data format definition by Electronic Arts. JPWS does not seek data interchange on field 66 but this may change in the future. The language used for the definition is a variant of the [Bachus-Naur-Form](https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form) , the JPWS [Data-Definition-Language](data-definition-language).

     <catalog> := 'CAT ' <length> <FORM-element>:n
     <FORM-element> := <raer> | <comp>

format-record-field-66 modified by Wolfgang Keller

Wolfgang Keller — Sat, 20 Aug 2016 10:35:24 -0000

--- v9
+++ v10
@@ -1,6 +1,6 @@
 ### Record Data Field 66

-JPWS Binary Data Catalog, Version 1, Description
+JPWS Binary Data Catalog, Version 1.1, Description (20.08.2016)
 This format for record field 66 is introduced with  *JPasswords* 0-8-0 and follows the guidelines of the IFF data format definition by Electronic Arts. JPWS does not seek data interchange on field 66 but this may change in the future.

     <catalog> := 'CAT ' <length> <FORM-element>:n
@@ -9,12 +9,12 @@
     <rear> := 'FORM' <length> 'REAR' <rear-chunk>:n

     <rear-chunk> := <chunk-type> <length> <chunk-name> [<chunk-data>]
-    <chunk-type> := 'PROP' | 'PTEX' | 'BLOB' | 'JPEG'
+    <chunk-type> := 'PROP' | 'PTEX' | 'BLOB' | 'JPEG' | 'SCPT'
     <chunk-name> := 4 bytes random binary
     <chunk-data> := <binary-data>

     <length> := 4-byte signed integer in BIG-ENDIAN (MSB first)
-    <ZIP-data> := byte:n
+    <ZIP-data> := <binary-data>
     <binary-data> := byte:n

@@ -31,9 +31,9 @@
                         bytes of <rear> minus 8.
 + <rear-chunk>: <length> denotes length in bytes for <rear-chunk> minus 8; <chunk-name>
                         may appear only once with type PROP and only once within all other types.
-+ <chunk-type> : 'PTEX' = plain text, 'PROP' = properties map (text), 'BLOB' = binary large object, 'JPEG' = JPEG image data.
-+ <chunk-name>: the chunk name has to be unique for a data entry in the catalogue. A data entry  can have two parts in the catalogue: PROP and one of the rest of the types. This is saying that PROP is an additional type to any occurring data type, it represents a Properties map (text) related to the data entry. There is no formal rule about the conjunction of both parts, i.e. any one can stand alone although an alone-standing PROP does not define a typed data entry and hence may not be accessible in a reading interface.
-+ <chunk-data>: for the types PROP and PTEX this is an UTF-8 serialisation of a text string;
++ <chunk-type> : 'PTEX' = plain text, 'PROP' = properties map (text), 'BLOB' = binary large object, 'JPEG' = JPEG image data, 'SCPT' = properties map (text) as a  document script.
++ <chunk-name>: the chunk name has to be unique for a data entry in the catalogue. A data entry  can have two parts in the catalogue: PROP and one of the rest of the types. This is saying that PROP is an additional type to any occurring other data type; it represents a Properties map (text) related to a data entry. There is no formal rule about the conjunction of both parts, i.e. any one can stand alone although an alone-standing PROP does not define or declare a typed data entry and hence may be ignored in a reading interface. The type SCPT is a properties map by itself and does not relate to a PROP entry, hence a PROP entry related to a SCPT is correct but meaningless.
++ <chunk-data>: for the types PROP, PTEX and SCPT this is an UTF-8 serialisation of a text string;
                          for type JPEG this is a valid JPEG compressed image format; for BLOB this is a 
                          format free block of binary data (opaque).