ࡱ > | } ~ 7 o bjbjUU 6 7| 7| U l vp vp vp 8 p q s v " v v v v v v $ v v v v v ʑ v v ʑ ʑ ʑ v v v ʑ v ʑ T ʑ v s `~= g vp n . $ 0 R @ s r X s ʑ ISO/IEC JTC 1 SC 24 N 2551
ISO/IEC JTC 1/SC 24/WG 8 N0342
COLLATION OF COMMENTS ISO/IEC CD 18023-3 Information technology Computer graphics SEDRIS Part 3: Transmittal Format Binary Encoding
Japan's comments on SC24 N 2515 SEDRIS Part 3 (CD)
2004-01-09, edited by Koreaki Fujimura
The national body of Japan disapproves CD 18023-3 for reasons as below. Acceptance of these reasons and appropriate changes in the text will change our vote to approval.
Japan_G001:
Global:
This document should be changed according to the expected changes in SEDRIS Part 1.
------------------------
Japan_T001:
Global, the data types SRM_xxx:
Problem: All the data types with the name SRM_xxx, except SRM_Direction, SRM_Hemisphere, and SRM_PS_Pole, are neither defined in this part nor in Part 1 (Part 1 does refer only SRM_Corrdinate and SRM_Coordinates_3D but does not define any SRM_xxx data types by itself).
Recommendation: They should be defined in this part, in Part 1, or in the SRM standard.
Japan_T002:
4.3.3.1, Fig.4.4:
Problem: The figure 4.4 is not visible.
Recommendation: The figure should be made visible.
Japan_T003:
4.3.4.2.3:
Problem: The texts including the term sentinel are hard to understand.
Recommendation: They should be clarified.
Japan_T004:
4.3.4.2.3:
Problem: The two formats for packed data types, integer and floating, overlap too much.
Recommendation: Those two formats should be merged.
Japan_T005:
4.3.4.2.3 (this may become moot by the disposition of the former comment):
Problem: The use of tolerance in the specification for packed floating data types is hard to understand.
Recommendation: It should be explained (if it does not become moot inspite of .
Japan_T006:
5.2.4:
Problem: The representations defined here are not used in the current draft and will be never used because they have no names.
Recommendation: This subclause should be removed.
Japan_T007:
5.3.2.1:
Problem: It is dangerous for the number data types to be specified in terms of Part 1 because the specifications in Part 1 are too much flexible as the specifications for platform independent interchanges.
For example, the specification for floating in Part 1 (CD2), quoted below, clearly states there are some
implementation dependent characteristics.
There are two precisions of floating point numbers specified as fundamental data types:
FloatLong_Float
These correspond to the single and double precision floating point types specified by IEC 60559:1989, Binary floating-point arithmetic for microprocessor systems (see HYPERLINK "E:\zcg\sedris\!SDR-CD2\Clause2--References.html" \l "IEC60559" 2.[IEC60559]). The specific values for POSITIVE_INFINITY and NEGATIVE_INFINITY shall be supported. However, implementations on architectures that support other floating point representations are allowed and shall support POSITIVE_INFINITY and NEGATIVE_INFINITY as provided in those floating point representations.
Recommendation: The number data types should be specified in this part so as to be uniquely encoded without implementation considerations.
US NB Position on
ISO/IEC Committee Draft 18023-3
The US votes to approve ISO/IEC CD 18023-3 with the following comments:
General
US_G001:
Check entire document for formatting. Some clauses have the words justified such as the Introduction and some of them have the words aligned left. The document shall be formatted per ISO/IEC directives with regard to justification and formatting.
US_G002:
Throughout the document the reference to the other Parts of 18023 are made inconsistently. Some time Part X of this International Standard is used other times Part X of 18023 is used as well as 18023-X. Refer to the directives for proper referencing of other parts of 18023 and make the hyperlinks referring to 18023 consistent.
US_G003: The first letters of the words of a phrase should be capitalized because they are indicating the letters used for the acronym such as, application program interface (API) and abstract transmittal format (ATF). See Introduction for API and Clause 4 for ATF. Research the ISO/IEC directives. Follow directives on capitalization of acronyms and abbreviations. Apply consistent usage throughout this International Standard.
US_G004:
Change all references to this International Standard to be Part 3 of this International Standard.
US_G005:
The terms "byte" and "octet" are used interchangeably in the text. For example, Figures 5.1 to 5.3 use the term 'byte" while the accompanying and following text use "octet". Need to be consistent and use octet in the figures and elsewhere.
US_G006:
The Encoding should be updated to be consistent with Part 1 of ISO/IEC 18023.
US_G007:
Verify the correct use of ISO capitalization for all subclause headings and paragraph text (some words/terms appear to not be proper names requiring capitalization, yet many are frequently capitalized throughout just the same). Italics should probably be employed in place of capitalization to identify significant terms. (For example, the heading 4.3.3 STF Object File should probably be 4.3.3 STF object file, and the text/paragraph reference to STF Object File should probably be changed to STF object file.)
Technical
Index
US_T001:
Problem: The Tile of the document needs to be changed
Recommendation: Recommend changing the Title to SEDRIS Transmittal Format binary encoding.
US_T002:
Problem: The Tile of the document needs to conform to directives. Currently it says Committee Draft ISO/IEC
Recommendation: Recommend changing to ISO/IEC Committee Draft.
US_T003: Table
Problem: The title for Clause 6 does not match the title in the list below the table.
Recommendation: Make the titles consistent
US_T004
Problem: On the Index Page under scope; change defines the problem area
Recommendation: to specifies the technology area that part 3 of this International Standard addresses.
Foreword
US_T005: 5th paragraph
Problem: has the words, Further parts will follow. Are these words required by ISO? If not, this is not an accurate statement. There are not any more standards being proposed for the SEDRIS Technology. The word will implies there are other SEDRIS Technologies that will follow in this series.
Recommendation: If this sentence has to remain, the word should be changed to may.
Introduction
US_T006: Purpose
Problem: The second and third paragraphs are not needed since it does not describe the purpose of 18023-3, but the overall purpose of 18023. If this is included here, than something similar should be included in 18023-2.
Recommendation: Use the following rewrite based on the Introduction of 18023-2.
"This part of ISO/IEC 18023 defines the binary encoding for SEDRIS transmittals that has been termed the SEDRIS Transmittal Format (STF). It defines an encoding that is fully compliant with 18023-2. This ensures that SEDRIS application program interface (API) permits applications to access, and consequently interchange, environmental data independent of any architecture and information storage technologies that a particular environmental data generation system or application uses."
Clause 2 References
US_T007:
Problem: Do not see use of ISO/IEC 10641
Recommendation: If not used, remove from Normative References
Clause 4 Concepts
US_T008: Clause 4.2
Problem: the acronym STF is defined again after it was defined in 4.1.1 and in the Introduction. After it is first defined, there is no need to further define it.
Recommendation: Just use the acronym.
US_T009: Figure 4.4Problem: Figure is missing so could not review.
Recommendation: Include Figure.
US_T010: 4.3.4.2.2 Partitioning the data, last 2 paragraphs
Problem: As per response to comment US T009 on WD1, need to make it clear that the equation applies to a sub-block.
Recommendation: Recommended text change:
The block_data_values in the n-dimesional array for a given block are sequenced such that the values along the last axis are stored in order, followed by the values of the penultimate axis continuing until the values of the first axis have been stored.
For the three-dimensional table example above, the ith element in the sequence for a specific block is specified by:
(x 30 25) + (y 30) + z
where (x,y,z) is the coordinate of the block_data_value in the three-dimesional array of the specified block.
US_T011 text and figure for 4.3.4.2.2 Partitioning the data
Problem: In Figure, max value missing for Axes 0 in Block 1. Much better than previous version. However, it is believed that it would still be good to modify the first sentence below the table
Recommendation: Change to read something like "The block_data_values in the n-dimensional array for a specific block are sequenced such that the values along the last axis are..." This would make it clear that the array being referenced is for a given block. Note that "dimensional" was misspelled in the original file.
Clause 5 Encoding of Data Types
US_T012: 5.2.3.1 Overview, 1st para., 1st sentence
Problem: Since we are using the term "octet", should not "byte chain encoded (BCE)" be "octet chain encoded (OCE)".
Recommendation: Suggest using OCE unless BCE is common terminology in the community.
US_T013: 5.3.1 Overview, 1st para., last sentence
Problem: The sentence needs to be clearer. Actually, is this statement actually needed. If the data type is not used in a transmittal, how could you encode it?
Recommendation: Recommend removing the sentence.
Clause 6 Transmittal Content Representation
US_T014: 6.3.122, 6.3.164
Problem: The object header parameters in the figure include [a, bb, cc, ddd], however the boxes that follow do not address the cc parameter.
Recommendation: Verify whether this is in error.
US_T015: 6.3.194, 6.3.195, 6.3.242
Problem: The object header parameters in the figure include [a, bb, ddd], however the boxes that follow do not address the ddd parameter.
Recommendation: Verify whether this is in error.
US_T016: 6.3.205
Problem: The object header parameters in the figure include [a, bb, cc, ddd], however the boxes that follow do not address the bb, cc, ddd parameters.
Recommendation: Verify whether this is in error.
US_T017: 6.4.1.5
Problem: The first of the three boxes is empty.
Recommendation: This box should not be empty.
Editorial
US_E001: All file headers
Make the SEDRIS logo appear the same size in all files (the logo in the index.html page and the Scope clause are larger than all others). Most files currently take a 200 x 200 pixel logo and shrink it to 131 x 131 pixels, which makes the logo blurred and irregular around the edges. If required, request the appropriate size logo for use from the SEDRIS organization. Appropriate SEDRIS logos are available in the following sizes (which should not be reduced in size when used): 75 x 75, 150 x 150, 200 x 200.
Index
US_E002: index.html page, 2nd paragraph (immediately following the table)
Change The Foreword provides for this part of ISO/IEC 18023 to read The Foreword provides for the SEDRIS standard to be consistent with the identical statements in ISO/IEC 18023-1 and 18023-2.
US_E003: index.html page, #6 in the list
Change 6. Class instance representation to read 6. Transmittal content representation as per the table in the index.html page and the actual Clause 6 title heading.
US_E004: First paragraph after table.
This paragraph contains three sentences, which in 18023-2 are three separate paragraphs which I believe is the correct approach. Split into three paragraphs as in 18023-2.
Foreword
US_E005: Foreword, 3rd paragraph
Change the hyperlink under HYPERLINK "http://www.vrml.org/" http://www.sedris.org to point to http://www.sedris.org rather than to http://www.vrml.org.
Introduction
US_E006: Introduction, Purpose, 2nd paragraph, 1st sentence
Change <>ISO/IEC 18023 specifies to read ISO/IEC 18023 specifies . Delete the extraneous <>.
Clause 2 Normative References
US_E007: 2, table
For the I18023-2 entry, delete the extra/blank line in the Reference column.
Clause 4 Concepts
US_E008: Figure 4.1
Correct the figure caption. The figure caption is missing the word Figure (as in Figure 4.1).
US_E009: 4.3.3.1, 2nd sentence
Change has the structure show in to read has the structure shown in .
US_E010: 4.3.3.1, 3rd paragraph
Change HYPERLINK \l "STFBlock"4.4.3.2 STF Block to read HYPERLINK \l "STFBlock"4.3.3.2 STF block. The numbering and capitalization are incorrect.
US_E011: 4.3.3.3, 1st paragraph
Correct the HYPERLINK "Clause6--TransmittalContentRepresentation.html" \l "DRMObjectRepresentation"6.3 DRM object representation hyperlink to read HYPERLINK \l "ObjectInstanceRepresentation"6.3 Object instance representation. It is mis-titled, and does not work properly because it points to an incorrectly named bookmark (only takes you to the top of Clause 6, not to subclause 6.3).
US_E012: 4.3.3.3, 3rd paragraph
Correct the HYPERLINK "Clause5--EncodingOfDataTypes.html" \l "STF_FBO"5.2.4.2 STF_FBO hyperlink to read HYPERLINK \l "ObjectInstanceRepresentation"HYPERLINK "Clause5--EncodingOfDataTypes.html" \l "STF_FBO"5.2.5.4 STF_FBO. It is mis-numbered, and does not work properly because it points to an incorrectly named bookmark (only takes you to the top of Clause 5, not to subclause 5.2.5.4).
US_E013: 4.3.4.1, 2nd paragraph
Correct the HYPERLINK \l "STFObjectFile"4.4.3 STFObjectFile hyperlink to read HYPERLINK \l "STFObjectFile"4.3.3 STF object file. The numbering, word spacing, and capitalization are incorrect.
US_E014: 4.3.4.1.c
Change DT_BLOCK_DATA, and to read DT_BLOCK_DATA, or. Since the object types are limited to one of these four types of objects, this should be identified by an or rather than an and.
US_E015: 4.3.4.1, last paragraph, 2nd sentence
Change A component object references from to read A component object reference from .
US_E016: 4.3.4.2.2, 2nd paragraph
Change the HYPERLINK \l "BlockDataFormatAndPacking"4.4.4.2.3 Block Data format and packing hyperlink to read HYPERLINK \l "BlockDataFormatAndPacking"4.3.4.2.3 Block data format and packing. The numbering and capitalization are incorrect.
US_E017: 4.3.4.2.3, 2nd paragraph
Correct the HYPERLINK \l "f_BlockDataValueFiveBitFields"Figure 4.5 hyperlink. It does not work because it points to an incorrectly named bookmark.
Clause 5 Encoding of Data Types
US_E018: Table 5.1
Correct the following inoperative hyperlinks: 5.2.4, 5.2.5, 5.2.5.1, 5.2.5.5, 5.3.3.12, 5.3.5.1, 5.3.7.7, 5.3.7.22, 5.3.7.67. Also change 5.3.7.75URN to read 5.3.7.75 URN (insert a space), and correct 5.3.7.32 to point to the correct location (it incorrectly points to 5.3.7.31).
US_E019: 5.2.1 Rules for encoding data types, last para., last sentence
The sentence is not clearly written.
Suggested rewording:
"For variant record types, the data shall be encoded such that the discriminant is encoded first, followed by the elements of the variant identified by the value of the discriminant."
US_E020: 5.2.2
Change this subclause number from 2.2 to read 5.2.2
US_E021: 2.2 STF primitive data types, 2nd & 3rd paragraphs
The sentences should start with 'The STF"
US_E022: 5.2.3.7
Correct the HYPERLINK \l "f_STF_ShortIntegerUnsignedFormulation"Figure 5.9 hyperlink to point to the correct location (it incorrectly points to Figure 5.8).
US_E023: 5.2.6, last sentence
Change This string data types is called to read This string data type is called .
US_E024: 5.3.2.1
Change HYPERLINK \l "BCE8Unsigned"5.4.2.2 BCE8_Unsigned to read HYPERLINK \l "BCE8Unsigned"5.2.3.2 BCE8_Unsigned. The numbering is incorrect.
US_E025: 5.3.2.1
Change HYPERLINK \l "BCE8_Signed"5.4.2.4 BCE8_Signed to read HYPERLINK \l "BCE8_Signed"5.2.3.4 BCE8_Signed (the numbering is incorrect), and correct it to point to the proper location (it is currently inoperative).
US_E026: 5.3.2.3
Change HYPERLINK "Clause2--References.html" \l "I10646_1"2.[I10646] to read HYPERLINK "Clause2--References.html" \l "I10646_1"2.[I10646-1]. The Clause 2 identifier is incorrect/incomplete.
US_E027: 5.3.3.1
Change HYPERLINK \l "BCE8Unsigned"5.2.2.2 BCE8_Unsigned to read HYPERLINK \l "BCE8Unsigned"5.2.3.2 BCE8_Unsigned. The numbering is incorrect.
US_E028: 5.3.4
Change HYPERLINK \l "BCE8_Signed"5.2.2.4 BCE8_Signed to read HYPERLINK \l "BCE8_Signed"5.2.3.4 BCE8_Signed (the numbering is incorrect), and correct it to point to the proper location (it is currently inoperative).
US_E029: 5.3.5.2, 5.3.5.3
Align the Bit 0 / Bit 1 columns.
US_E030: 5.3.5.4
Align Bit 0 with the Bit 129 column.
US_E031: 5.3.7.1, last sentence
Change that may be exist in an STF to read that may exist in an STF.
US_E032: 5.3.7.8, 5.3.7.15
Verify whether geodetic_longitude : SRM_Long_Float should appear in a box.
US_E033: 5.3.7.31
Verify whether geodetic_latitude : Long_Float should appear in a box.
US_E034: 5.3.7.68
For SRF_type = GC, change No additional information encoded to read No additional information is encoded for consistency with other entries in this subclause.
Clause 6 Transmittal Content Representation
US_E035: Table 6.1
Add a space character between the subclause number and the subclause title for 6.1, 6.2 and 6.3.
US_E036: Table 6.1
Correct the following inoperative hyperlinks: 6.3.4, 6.3.5, 6.3.7 6.3.9, 6.3.13, 6.3.14, 6.3.25, 6.3.26, 6.3.63, 6.3.71, 6.3.83 6.3.87, 6.3.96, 6.3.98, 6.3.99, 6.3.132 6.3.134, 6.3.136 6.3.139, 6.3.148, 6.3.177, 6.3.213, 6.3.226, 6.3.250, 6.3.264, 6.3.265, 6.4, 6.4.1.3, 6.4.1.5, 6.4.2.
US_E037: 6.2.1
Change (specified in HYPERLINK "Clause2--References.html" \l "I18023_1"part 1 of ISO/IEC 18023) to read (see HYPERLINK "Clause2--References.html" \l "I18023_1"2.[I18023-1]).
Correct the HYPERLINK "t_ObjectStructure"Table 6.2 hyperlink to point to the correct location.
US_E038: 6.2.2, 1st paragraph
Correct the HYPERLINK "t_ObjectStructure" HYPERLINK "http://www.sedris.org/wg8home/wg8/18023-3_CD/" \l "fObjectHeaderFormulation" Figure 6.1 hyperlink to point to the correct location.
US_E039: 6.2.2, 2nd paragraph
Change >CC is the association count field to read CC is the association count field. Delete the extraneous >.
US_E040: 6.2.5, 2nd paragraph, 1st sentence
Reference should be to a specific subclause in Clause 4 and provide a hyperlink.
US_E041: 6.2.6
Correct the HYPERLINK \l "f_FieldFormulation"Figure 6.8 hyperlink to point to the correct location.
US_E042: 6.3.107, 6.3.233
Add a space character between the subclause number and the subclause title.
US_E043: 6.3.108, 6.3.109
The object header parameters in the figure appear as upper-case (A, BB, CC, DDD), however the boxes that follow reference the parameters as lower-case (a, bb, cc, ddd). Correct the inconsistency.
US_E044: 6.3.187
Correct the font used for this subclause number / title. A text paragraph font style is used, rather than the font style for a header.
US_E045: 6.4.3.4
Correct the HYPERLINK \l "DRMObjectRepresentation"6.3 DRM object representation hyperlink to point to the correct location.
US_E046: 6.4.4.2
Correct the HYPERLINK \l "tDTDATAObjectStructure"Table 6.3 hyperlink to point to the correct location.
US_E047: 6.4.4.3, 2nd sentence
Change Imediately to read Immediately .
Clause 7 Conformance
US_E048: Table 7.1
Change HYPERLINK \l "ConformanceOfInterpreters"7.2.3 Conformance of interpreters< to read HYPERLINK \l "ConformanceOfInterpreters"7.2.3 Conformance of interpreters. Delete the extraneous <.
US_E049: 7.2.3, last sentence
Change that confrms to the requirements to read that conforms to the requirements .
UK National Body Comments on
SEDRIS Part 3 Transmittal format binary encoding
Committee Draft ISO/IEC 18023-3
(ISO/IEC JTC 1/SC 24 WG 8 N0321)
The UK votes to DISAPPROVE CD 18023-3 for the reasons given below. Acceptance of these reasons and appropriate changes in the text will change the vote to APPROVAL.
The UK National Body was not able to obtain a consensus on comments UK_G007, UK_T001, UK_T003, UK_T014 and UK_T017. Individual opinions and counter-opinions have therefore been given for each of these comments to assist discussion and resolution at the editing meeting.
General
UK_G001:
Entire document
HTML fails validation. As with previous versions, many of the html files were submitted to the W3C validation service. Responses to accepted comments on previous versions had agreed to make the html valid and conforming. All files that we submitted failed validation, so this has not been done.
Here is one example for file: index.html:
This page is not Valid HTML 4.01 Transitional!
Below are the results of attempting to parse this document with an SGML parser.
1.Line 18, column 51: required attribute "ALT" not specified (explain...).
^
2.Line 118, column 27: end tag for element "SPAN" which is not open (explain...).
Definitions defines the terms used within this part of
UK_G002:
Entire document
Alternative text string representations should be provided for all images (in case a browser cannot display them and also as an aid to the disabled). Use of this ALT attribute is required by the HTML 4.01 transitional specification.
UK_G003:
Entire document
Html page footer. Each html page should carry a footer with a hyperlink to the full document at the ITTF website where publicly available standards are posted. This is also for consistency with the EDCS.
UK_G004:
Entire document
ISO templates. The text and style found in the latest ISO templates should be used (with adaptations to html as appropriate). Note that Clause 7 of Part 2 of the ISO Directives tells us to use these templates:
7 Preparation and presentation of documents
The templates prepared by ISO and IEC shall be used for the preparation of documents. The templates and guidance on usage are available on the ISO web site ( HYPERLINK "http://www.iso.ch/sdis" http://www.iso.ch/sdis) and the IEC web site ( HYPERLINK "http://www.iec.ch/contents.htm" http://www.iec.ch/contents.htm).
Note that these templates and the supplemental files associated with them that are also available on the SDIS web site) contain the latest, revised boilerplate text that should be used in drafting ISO standards. Submitting correct text to ITTF will avoid unnecessary delays in the processing of this International Standard.
UK_G005:
Entire document
Links between Part 3 and Parts 1 and 2. There are very few explicit ties between the encoding in Part 3 and any material in either Part 1 or Part 2. An implementer must assume that symbols in the abstract syntax in Part 2 and the semantic specifications in Part 1 are related to similarly named items in Part 3. Explicit links to the other parts should be added everywhere so that all ambiguity is removed.
Here are a few examples:
1. In 4.3.1 the second sentence says
An STF-encoded SEDRIS transmittal shall contain:
exactly one STF-encoded SEDRIS transmittal root file,
one or more STF-encoded SEDRIS transmittal object files, and
zero or more STF-encoded SEDRIS transmittal image data and SEDRIS transmittal data table data files (called ImgDTData files)...
This is specified in Part 2 in the formal grammar. To say it in a potentially different way here with no reference to Part 2 is confusing (which should an implementer follow?) and may lead to unintentional incompatibilities. In fact, as pointed out in UK comments on Part 2, the above statement directly conflicts with the formal grammar in Part 2 that states:
::=
*
::= |
|
because the above formal, abstract grammar does not state that a must contain one or more STF-encoded SEDRIS transmittal object files or even any s at all!
Further, the language here is far too informal and is not explicitly tied to concepts defined in Part 2.
Here is a suggested re-write that references Part 2 and uses the correct concepts. This is changed to match the formal syntax in Part 2, even though it may be Part 2 that actually needs to be changed:
As specified in the abstract syntax in 5.2.3 of Part 2 of this International Standard, an STF-encoded SEDRIS transmittal contains:
exactly one STF-encoded ,
zero or more STF-encoded s each of which may either a a , a , or a .
2 As another example, consider 6.3.1 that specifies the encoding of DRM_Absolute_Time_Interval. We are left to assume that this element represents the similar element that is implied to be in Part 2 (UK comments on Part 2 cover that issue) and whose full abstract syntax and semantics are specified in Part 1. The only tie to Part 1 is in 6.2.1 that addresses the Template for object layout where it says Each instantiation of a DRM class (specified in part 1 of ISO/IEC 18023) is an object within the transmittal.
It would be best if each encoded representation of a DRM class in Clause 6 made an explicit reference back to its definition in Part 2 (which, if a UK comment is accepted will be by reference to Part 1) as well as to Part 1. Failing that, at least we need a very explicit and unambiguous statement right at the top of Clause 6 that ties the elements being encoded to both Part 2 and Part 1.
The following suggested minimal text corrects the problems highlighted in this example:
Replace the first sentence of 6.1.2 with:
This clause specifies a binary encoding of the abstract syntax of each DRM class that may be represented in a SEDRIS transmittal. The abstract syntax of each DRM class is specified in 5.x.x [to be added, based on UK G006 for Part 2] of Part 2 of this International Standard.
(This leaves it up to Part 2 to refer back to Part 1.)
At the top of 6.3 (Object instance representation ), where all of the encodings are specified, it should be explicitly stated how the names found in that subclause tie to and represent the same concepts defined in Parts 1 and 2. Note that 6.2.6 (Fields) never says how the field names relate to either Part 1 or Part 2. Some of the suggested text below might go into 6.2.6 instead:
6.3.1 Introduction
The encoding of each DRM class that may be represented in a SEDRIS transmittal is specified in one of the subclauses below. These DRM classes are specified by name in Tables 6.4 through 6.325 of Part 1 of this International Standard.
EXAMPLE The DRM class DRM_Absolute_Time_Interval whose encoding is specified in 6.3.1 is specified in Table 6.4 of Part 1 of this International Standard.
The fields encoded by the DRM class encodings below are also specified by name in Tables 6.4 through 6.325 of Part 1 of this International Standard.
EXAMPLE The fields of DRM class DRM_Absolute_Time_Interval whose encoding is specified in 6.3.1 are specified in Table 6.4 of Part 1 of this International Standard. The fields specified in the encoding (time_significance, delta_days, delta_hours, delta_minutes, and delta_seconds) have the same names, are specified in the same order, and have the same types as the field elements specified in Table 6.4 of Part 1 of this International Standard.
Based on the above and the examples, corresponding changes should be made throughout the text of Part 3.
UK_G006:
Entire document
Consistent language is needed throughout. The term element should be used consistently to mean any defined element in the BNF of the abstract syntax (at any level of abstraction). At present, many different terms such as entry and component are used for this.
UK_G007:
Entire document
All abstract syntax specification should be done in a manner consistent with the specifications in Part 2. All of this material should be moved to Part 2 (as addressed by UK comments on Part 2). It is extremely important not only for consistency among encoding, but also for ease of implementation, that all abstract syntax be in one location (even if sometimes by reference) and not scattered in three different parts, sometimes in subclauses with unexpected names. Also, at preset, an implementer must deal with the same type of abstract syntax information specified in many different styles, sometimes formally in BNF in Part 2 and other times informally in English language text in Part 3.
The UK also submits the following alternative opinions - highlighted in yellow;
Opinion 2
I do not believe there is any abstract syntax specification in Part 2. All specifications are for binary encoding. I do not understand the statement about scattering, since this is not the case here. Note also that there is no requirement and, in fact, no benefit to using the same expression technique in the abstract encodings to the concrete binary encoding, as the information to be presented is quite different.
Opinion 1 Response
Part 2 *is* the specification of the abstract syntax. If that is not what is there, then the authors of the document completely misunderstood the purpose that WG 8 wanted to achieve by directing them to provide a specification of the abstract syntax. Not only is this essential to enable different encodings to be created and to allow easy translation between encodings, but -- just like language binding exercises -- building a complete abstract syntax makes sure that the design is complete and consistent.
Opinion 2 Response
I think that you are thinking that the "abstract syntax" is more concrete than I believe it should be. The "abstract syntax" should NOT specify any organization items needed by a particular encoding. This includes such things as pointers that allow content to be organized in a more random fashion as is done in the binary encoding. A clear text encoding may not want, or even need, to do this.
Appendix UK-A gives the complete rewrite needed to deal with the abstract syntax specification for object header (that would go into Part 2) as well as the replacement text for the present description of object header in Part 3. If this comment is accepted, the UK expects that it can draft all the other revised text for the Editor by the conclusion of the Editing Meeting or shortly thereafter:
The text given in Appendix UK-A is suggested for Part 2. Note that much of the missing syntax and semantics, not present in Part 3 at present, is rigorously provided. This increases the amount of text, but the missing semantics need to be provided anyway:
The UK also submits the following alternative opinions - highlighted in yellow;
Opinion 2
This mistakenly seems to indicate that count fields and other such information are part of the abstract SEDRIS transmittal. In fact, such information is only needed by the binary encoded and should only be defined here. Moreover, the suggested syntax is wordier and much more difficult to understand than the more pictorial layout used in Part 3.
Opinion 1 Response
As to counts, they are very much a concept from the object models in Part 1, because association, composed of, and component of are all parts of each DRM class specification. Therefore these relationships must be present in any encoding, so the counts and lists in the binary encoding are not things that are unique to that encoding. They belong in the abstract syntax specification that is normatively referenced by every encoding.
Opinion 2 Response
Yes, but they do not need to be counted in every encoding. In some encodings, the "count" can be simply the number of items in a list. Therefore, the count should NOT be part of the abstract syntax. There should only be an abstract list of items.
Supplementary Comment from Opinion 1
Finally, it is emphasized again that there are two different grammars that are being talked about here. There is one for what we call the logical structure of a transmittal and one for what we call the layout structure. The later is in Clause 4 of Part 3, but belongs in Part 2 in our opinion because we see no reason why the layout would change for different encodings. The former is partially in Part 2 and partially in Part 1, with a few scattered pieces in Part 3. The former (logical structure of a transmittal) is what most needs to be pulled together in one place.
Response to Supplementary Comment from Opinion 2
I disagree wholeheartedly. The layout is encoding dependent and should be specified as appropriate for each encoding to satisfy the specific requirements of that encoding technique. Only the logical encoding should be in Part 2 as this is the only part that is "abstract".
UK_G008:
Entire document
The content of part 3 should be updated to correspond to the functionality defined in Parts 1 and 2.
Foreword
UK_T001:
Foreword title
For consistency with EDCS and with good practice, the title at the top of each subclause should not be:
ISO/IEC 18023-3 Transmittal format binary encoding
but rather should be
SEDRIS, Part 3: Binary encoding
The UK also submits the following alternative opinions - highlighted in yellow;
Opinion 2
Since this title is a substitute for the page numbers of the templates, they should provide the same information, which includes the ISO number. EDCS should be changed to conform to the directives.
Opinion 1 Response
EDCS is already finalized and the last editing meeting has been held and the last disposition of comments generated and mostly applied. ITTF has approved of its publication format including its headers.
Opinion 2 Response
Since the FDIS text has not yet been published, it is not too late to change. Foisting an
inappropriate result on the rest of the standards is not a proper thing to do. Note that I have been very unhappy with some of the decisions being made by the ISO editors without regard to the requirements of the standards community. This is just one example.
UK_T002:
Foreword, fifth paragraph
The statement Further parts will follow. is inappropriate and should be removed. There are at present no NPs to create any other parts. Part 2 of the ISO Directives is quite clear that other parts must referred to specifically by title:
5.2.1.3 If a document is published in the form of a number of separate parts, the first part shall include in its foreword (see 6.1.3) an explanation of the intended structure. In the foreword of each part belonging to the series, a reference shall be made to the titles of all other parts that have been or are planned to be published.
UK_T003:
Foreword, first paragraph, last sentence
The sentence See HYPERLINK "http://www.iso.org/" http://www.iso.org for information on ISO and HYPERLINK "http://www.iec.ch/" http://www.iec.ch for information on IEC. is unnecessary in an html document. Instead the hyperlinks should be hidden on the names ISO and IEC in the first sentence.
The UK also submits the following alternative opinions - highlighted in yellow;
Opinion 2
The exact wording, as required for a text document, is provided and should be used. When an HTML document is printed, the hyperlink information is otherwise lost.
Opinion 1 Response
EDCS has set the precedent and this wording was approved by ITTF following a detailed review this past April. If WG 8 feels that consistency in this area is not important, then this comment can be ignored.
Opinion 2 Response
I think that this is another example of what was mentioned immediately preceding (re: UK T001).
Introduction
UK_T004:
Introduction, throughout
The two sub-titles of the two unnumbered subclauses (Purpose and Design goals) should be removed.
UK_T005:
Introduction, first paragraph of Purpose
This part says:
This part of ISO/IEC 18023 defines the binary encoding for SEDRIS transmittals that has been termed the SEDRIS Transmittal Format (STF).
Better wording is:
This part of ISO/IEC 18023 defines a binary encoding the abstract transmittal format specified in Part 2 of this International Standard.
The reasons for this are:
1. If this is called the SEDRIS Transmittal Format (STF) then lets use only a single name for things and not many different equivalent names. If this is an important historical note, then lets make it a NOTE.
2. This is the binary encoding of Part 2 so it should have a corresponding name, not a different one.
3. We admit that private encodings are OK, so this is not the binary encoding but rather a binary encoding.
UK_T006:
Introduction; Purpose, second paragraph and third paragraphs
These entire paragraphs should be removed, as it is not appropriate for a part (other than the first part) to explain the purposes of all the parts. If this material is present, it belongs in Scope, and not in Introduction, and then only in Part 1. Reference: ISO Directives, Part 2, subclauses 6.1.4 and 6.2.1.
UK_T007:
Introduction; Design goals
This whole portion of text should be reworded as follows:
The design goals for the abstract transmittal format and all concrete encodings are:
present textrevised textThe following design goals were followed when designing the STFThis International Standard was developed to fulfil the following requirements:The SEDRIS API can be implemented for this format[delete this design goal]The design should be platform independent.the design shall be platform independent;Everything in the SEDRIS data representation model should be able to be captured, but not necessarily using the same structures.completely encode the SEDRIS data representation model;Lossless compacting of the data should be allowed.support lossless compression;each encoding shall be as efficient as possible, both when reading and when writing; allow the development of encodings that may be efficiently read and written;The STF should be as efficient as possible for general purpose use of the API. Efficiency is balanced in that it is not tailored to specific transmittal configurations or API usageisolate the SEDRIS API from the encoding format of SEDRIS transmittals; andExisting standards should be used for external resourcesleverage existing standards.
1 Scope
UK_T008:
Scope, first sentence
Change;
This part of ISO/IEC 18023 specifies a binary encoding format for SEDRIS transmittals.
to;
This part of ISO/IEC 18023 specifies a binary encoding for the abstract syntax of a SEDRIS transmittal.
This is for more consistent language and cleaner wording that captures the essence of this part.
UK_T009:
Scope, second sentence
This sentence: This format conforms to parts 1 and 2 of ISO/IEC 18023. should be removed. A scope statement should not state conformance requirements.
The ISO Directives, Part 2 in 6.2.1 states:
"This element shall appear at the beginning of each document and define without ambiguity the subject of the document and the aspects covered, thereby indicating the limits of applicability of the document or particular parts of it. It shall not contain requirements.
...
The scope shall be succinct so that it can be used as a summary for bibliographic purposes."
2 Normative references
3 Definitions
4 Concepts
UK_T010:
4.3.1, item C in the list
Statements like: SEDRIS transmittal data table data files (called ImgDTData files) are confusing because two different names for the same concept are introduced. Instead, the single name from the abstract syntax in Part 2 should be used, namely .
UK_T011:
4.3.3.3, second sentence
The sentence says: The format of the DRM fields is defined in 6.3 DRM object representation. The hyperlink (as with so many others on Clause 4) fails. There is no 6.3 DRM object representation . It is possible that this should be 6.3 DRM object instance representation
UK_T012:
Figure 4.4
The figure does not display.
UK_T013:
4.1.1, first sentence
The sentence: The abstract transmittal format (ATF) is the standard interchange mechanism for SEDRIS transmittals as defined in ISO/IEC 18023-2 (see 2.[I18023-2]). has several problems:
1. The abbreviation abstract transmittal format (ATF) is not uniformly used in Part 2. Further, it is an abstract syntax for a SEDRIS transmittal and not an abstract transmittal format.
2. The reference to Part 2 is improper. See 6.6.7.2, References to the document as a whole in its own text of the ISO Directives, Part 2, which says:
For a document published in separate parts, the following forms shall be used:
"this part of ISO/IEC 2382" (reference to a part only);
"IEC 60335" (reference to a whole series of parts).
3. ISO standards are to be referenced by name and not by bibliographical callouts such as 2.[I18023-2]). The hyperlink can be put on the standard, as we are doing in EDCS.
The following revision is suggested:
The abstract syntax of SEDRIS transmittals is specified in Part 2 ISO/IEC 18023.
5 Encoding of data types
UK_T014
5.2.5.4, Throughout
This is only one example of the serious deficiencies in Clause 5. In this example, this subclause says:
5.2.5.4 STF_FBO
file_index : BCE8_Unsigned (range: [1,30000])
block_index : BCE16_Unsigned (range: [0,4095])
object_index : Byte_Unsigned (range: [0,255])
The problem with this and most other similar specifications is that the requisite abstract syntax is missing on Part 2. In this case, the following should be in Part 2:
::=
::=
::=
::=
With this, 5.2.5.4 becomes:
5.2.5.4 Encoding of
The abstract syntax element is encoded as a BCE8_Unsigned with the additional restriction that the range is [1,30000].
The abstract syntax element is encoded as a BCE16_Unsigned with the additional restriction that the range is [0,4095].
The abstract syntax element is encoded as a Byte_Unsigned with the additional restriction that the range is [0,255].
Similar changes should be made throughout Clause 5 and Clause 6 so that appropriate abstract syntax is defined in Part 2 and then used throughout Part 3.
The UK also submits the following alternative opinions - highlighted in yellow;
Opinion 2
This comment is wrong! The abstract syntax does not need this data type at all. In
fact, this is the type of information that is encoding specific and should not be in Part 2. This comment should not be submitted.
Opinion 1 Response
This comment points out serious errors and omissions in the present document. All you need to do is read the comment with the eye of a disinterested party to see this. The authors of this document have failed to understand WG8's directions in the past that the abstract syntax be specified separately from the encoding.
The comment certainly needs to be submitted and we need to have the discussion in WG 8.
Opinion 2 Response
This comment points out serious misunderstandings about the information that should be in encodings. Every encoding has constructs that are particular to its own requirements. This is also true of CGM that even a cursory examination would reveal.
6 Transmittal content representation
UK_T015:
6.1.2 Description
The title of this subclause should be renamed to Overview, because that term is more descriptive of what the contents should be.
UK_T016:
6.4.1.2 Master File Table
The Master File Table shall start at the offset given in the Root File Header. The Master File Table shall contain the list of STF Object and STF ImgDTData files that make up the transmittal. Each entry in this list shall be a NULL terminated file name (i.e., a string of type STF_Characters). An index into this table shall be used to identify in which file an object is stored. The F in an FBO object reference shall be an index into the Master File Table.
--- URIs should be used as file names. This has many advantages including allowing files to be fetched and transferred only as needed.
UK_T017:
6.3, throughout
All of the encoding specifications begin with the same, mostly repeated data similar to:
76543210abb00001
field offset as specified by a
aggregate count if bb = 11
aggregate reference list containing items as specified by bb
component reference list containing one item
This information presentation is confusing on several counts:
1. It gives information that is already specified in 6.2.2. For example, field offset as specified by a. Note that the presence or absence of other fields in the header is fully specified in 6.2, therefore there is no reason to indicate their presence or absence again here.
The UK also submits the following alternative opinions - highlighted in yellow;
Opinion 2
This comment seems to miss the fact that each of these specifications is different. It is clearer to provide the explicit specification for each element, while allowing 6.2 to specify the template under which each of the encoded elements is described. I do not agree with removing this information, as I believe that this will be highly misleading to an implementer. However, I do agree that the wording can be made more consistent.
Opinion 1 Response
The counterargument is that a substantial part of each of these specifications is determined by the DRM class specifications in Part 1. There is no need to repeat information that can be said once. For example, why re-list each field and its type, since that can be done quickly by reference to Part 1?
Opinion 2 Response
Agreed. However, it is important that the exact layout of the bits, when combined into a bigger structure, is specified. This is not specified in Part 1 and is inappropriate for part 2. Therefore, it needs to be done in Part 3.
Opinion 1 Response
Further, the present format fails to state the rationale for count values, nor does it specify what (references to) other DRM classes are included in the lists. This is a serious deficiency that the revised wording corrects.
Opinion 2 Response
It is inappropriate to place "rationale" information in an International Standard, as has been stated many times. If a "rationale" document is desired, let a project be initiated to do so.
2. It expands on the meaning of some fields specified in 6.2.2 and interprets their meaning. For example, rather than saying the component count field is set to 001 it says component reference list containing one item.
3. It uses confusing. 6.2.2 uses field names A, BB, CC and DDD. Here we see lower case letters without any explanation that they represent actual field contents. Since the field names are specified in 6.2.2 why not use them if that is necessary?
4. It uses inconsistent specification style. For example, 6.2.2 says that if A is 1 then there is a field offset, while the sentence above says field offset as specified by a rather than field offset if a = 1 which is the style used in the next specification aggregate count if bb = 11.
5. Some fields are indicated even though they may not be present. In the example, field offset and aggregate count may neither actually be present.
We suggest a much more compact and consistent presentation style that uses the form of statements either as a single sentence or a list of one of the forms:
One of:
The field offset bit of the object header control octet shall contain ...
The aggregate count field of the object header control octet shall contain ...
The association count field of the object header control octet shall contain ...
The component count field of the object header control octet shall contain ...
or, if there is more than one restriction, a sentence and a list (with only the necessary items present) of the form:
The fields of the object header control octet are restricted as follows:
the field offset bit of the object header control octet shall contain ...
the aggregate count field of the object header control octet shall contain ...
the association count field of the object header control octet shall contain ...
the component count field of the object header control octet shall contain ...
The UK also submits the following alternative opinion - highlighted in yellow;
For item 5, it is my opinion that the suggested wording is significantly less clear than the graphical presentation already used.
Here are a few examples (for item 5):
1. The example initially cited above is from 6.3.1 DRM_Absolute_Time_Interval and reduces to:
The component count field of the object header control octet shall contain 001.
Note that the presence or absence of other fields in the header is fully covered in 6.2, therefore there is no reason to indicate their presence or absence here.
2. The text to be added to specify the necessary STF_Octet type is
5.x.x.x STF_Octet
The length of an STF_Octet element is one octet. Figure 5.x specifies this data type. The meaning of each bits shall be specified each time this type is used to encode an element of abstract syntax.
76543210abcdefghFigure 5.x STF_Octet formulation
The UK also submits the following alternative opinions - highlighted in yellow;
Opinion 2
It is not clear why this element is needed. If it is desired that the STF_Byte data type be renamed to STF_Octet, then simply state that.
Opinion 1 Response
The reason for not just saying this is that we were not certain of all of the uses that STF_Byte might be put to. We can discuss this at the editing meeting and if this type is used solely for octets of data (and not used, for example, for character string contents specifications), then this might be the agreed change.
Opinion 2 Response
I have no objection to dividing the use of STF_Byte into a use as an eight-bit signed integer and using STF_Octet as an eight-bit field.
UK_T018:
Table 6.2, second line
This indicates that field offset is always present because there is no (if needed) following it as in many other lines in the table. However, 6.2.2 states:
A is the field offset bit:
0 The field offset is not provided.
1 The field offset is provided and specifies the offset in octets from the beginning of the object to the first field.
indicating that the presence of this field is optional. It is uncertain which is intended, but these do need to be made consistent.
UK_T019:
6.2.4 throughout and title
This subclause states: These entries shall exist if their respective object header bits are set to their maximum values. When provided, these count entries specify the number of items in the reference lists for the respective list type.
It never states what counts are referred to leaving the reader to guess. It should be reworded:
The aggregate count, associate count, component count elements shall be present depending on the values of the corresponding object header fields (the aggregate count field, association count field, and component count fields, respectively) (see 6.2.2). Each count element specifies the number of items in the reference list for the respective list type (aggregate list, associate list, and component list, respectively).
UK_T020:
6.2.2, the first item in the where list
A , now called the field offset bit, should be renamed the field offset field for consistency with the names of the other fields in this octet.
UK_T021:
6.2.3 throughout plus Table 6.2 and 6.2.2
This specification of field offset says:
If the A bit of the object header has value one, this field shall exist and specifies the number of octets from the beginning of the object to the first octet of the object-specific data.
It is not clear what is the first octet of the object-specific data. Note that in 6.2.2. it states (bold added):
A is the field offset bit:
0The field offset is not provided.
1The field offset is provided and specifies the offset in octets from the beginning of the object to the first field
while Table 6.2 in the last row says (bold added): Object-specific data including fields (if needed).
Combining these two inconsistent specifications leads us to believe that the only object-specific data must be fields.
These different statements should be made consistent.
UK_T022:
6.2.5 , first sentence
Here we are told (bold added):
Immediately following the object header are the aggregate, associate and component object reference lists.
In Table 6.2 these are called simply aggregate list, associate list, and component list respectively. Similar terms are used in 6.2.2. Now they are given a different name. Very confusing.
The names need to be made consistent throughout.
UK_T023:
6.2.5, second paragraph
This paragraph says:
As described in Clause 4, an object reference is defined as three indices which are together called the FBO of the object.
An explicit reference that is needed is absent, so this can be found only by a search of Clause 4 on FBO (it is in 4.3.3.3 Object data and object referencing). The following points apply;
1. The abstract syntax of object reference or FBO belongs in Part 2 and should be added there.
2. This is a prime example of how hard it is to check the present three part specification for the numerous logical inconsistencies that it contains unless the entire abstract syntax is condensed into a single location, as requested by the Part 2 comment, UK G006 (last paragraph).
UK_T024:
6.3 throughout
An earlier UK comment described how the front material in each specification (the elements above object-specific fields) can be mostly eliminated. In addition, there needs to be an explanation in Part 3 of the rationale for why some object representations require component references. We present a needed change by way of an explicit example:
In Part 3 6.3.1 (DRM_Absolute_Time_Interval) we see that the object representation contains a "component reference list containing one item". Looking back into Table 6.4 (DRM_Absolute_Time_Interval) in Part 1, we see that this DRM Class is composed of one other class: . It is this composition that gives rise to the component reference list. But Part 3 gives no hint that the list item in the component reference list must be an object instance of . Rather than forcing a reader to go back to Part 1 and figure this out, this should be made explicit. This would also make the encoding better specified (we are left to guess that the list item in the component reference list must be an object instance of ).
In an earlier comment we suggest replacing the first five lines of the table in 6.3.1 with:
The component count field of the object header control octet shall contain 001.
Now we suggest that this be supplemented to indicate the type of component that must be present in the component list:
The component count field of the object header control octet shall contain 001 to indicate that a component list shall be present and that it shall contain a single reference to an object instance of type (see Table 6.4 of Part 1 of 18023).
Similar changes should be made throughout 6.3.
UK_T025:
6.3 throughout
Earlier UK comments have suggested how to simplify initial rows of the object instance specifications in 6.3. This comment deals with simplifying the later rows that list the object specific fields.
First, if the types specified in the abstract syntax in Part 1 are always encoded the same way using the encoding types of Part 3, then this information can be given only once in Part 3 and the simply referred to in each object instance encoding rather than being repeated each time. Again we proceed by giving a specific example:
In 6.3.1 we see that the encoded representation of an object instance of class DRM_Absolute_Time_Interval has five fields coded as follows:
time_significance : Time_Significance
delta_days : Integer
delta_hours : Byte_Unsigned
delta_minutes : Byte Unsigned
delta_seconds : Long_Float
In Part , Table 6.4, we see that these fields are defined in abstract syntax as:
field_namerangeField_Data_Typetime_significanceTime_Significancedelta_daysIntegerdelta_hour0..23Byte_Unsigneddelta_minutes0..59Byte_Unsigneddelta_seconds[0, 60)Long_Float
Of course there is a problem because the abstract types of Part 1 have the same names as the encoded representations used in Part 3 (and as the implied abstract syntax to be incorporated by reference into Part 2 by another UK comment). This is dealt with in other UK comments. Ignoring that for the moment, we suggest adding a table into Clause 6 that specifies how all the abstract field types in Part 1 are to be encoded. It will contain in part:
6.x.x Field values are specified in 6.2.2 of Part 1 of 18023 using data types specified in 5.2 and 5.3 of Part 1 of 18023. When these types are used to specify the type of a field in 6.2.2, that field is always encoded the same way in this part of 18023. This encoding is specified in Table 6.x.
Table 6.x Field data type encoding
Field_Data_TypeEncodingTime_SignificanceTime_SignificanceIntegerIntegerByte_UnsignedByte_UnsignedByte_UnsignedByte_UnsignedLong_FloatLong_Float
Once the above is stated once the specifying the encoding all fields can be done reference. In the above example, suggested text is:
Each field of specified in Table 6.4 of Part 1 of 18023 shall be encoded as specified on Table 6.x.
Therefore, summarizing several UK comments together, the specification of the object instance encoding of reduces to two sentences rather than a table containing 10 rows:
6.3.1
The component count field of the object header control octet shall contain 001 to indicate that a component list shall be present and that it shall contain a single reference to an object instance of type (see Table 6.4 of Part 1 of 18023). Each field of specified in Table 6.4 of Part 1 of 18023 shall be encoded as specified on Table 6.x.
Editorial
1 Scope
2 Normative references
UK_E001:
2, Table
There is an extra, blank line in the entry for I18023-2 in the table
3 Definitions
4 Concepts
UK_E002:
4.3.3.3, third paragraph
This paragraph says: The encoding of an FBO shall be as described in 5.2.4.2 STF_FBO. The link on 5.2.4.2 fails but it appears intended for 5.2.5.4
5 Encoding of data types
6 Transmittal content representation
UK_E003:
6.2.2 Object header, third item in the "where" list
There is a stray ">" in ">CC".
UK_E004:
6.3.1 DRM_Absolute_Time_Interval in the table
There is an underscore missing in "delta_minutes : Byte Unsigned"
Since two missing underscores were found in the first two encodings we inspected, the Editor should be instructed to inspect the remainder of Clause 6.3 for missing underscores and make the necessary corrections.
UK_E005:
6.3.2 DRM_Absolute_Time_Point, in the table
There is an underscore missing in "time_configuration : Time Configuration"
Appendix UK-A
Abstract Syntax Specification Text to supplement UK G007
5.x.x
The abstract syntax of the element is specified by the following formal grammar:
::= * * * * * * *
::=
::= |
where:
means that the element of the is not present, and
means that the element of the is present.
::= | | | |
where:
means that neither the nor the elements of the are present;
means that the element of the is not present, the element of the is present, and the contains exactly one occurrence of the element,
means that the element of the is not present, the element of the is present, and the contains exactly two occurrences of the element;
means that the element of the is not present, the element of the is present, and the contains exactly exactly three occurrences of the element;
means that the element of the is present, that the element specifies a number of aggregates that is four or greater, the element of the is present, and the contains exactly the number of occurrences of the element that the specifies.
::= ::= | | | |
where:
means that neither the nor the elements of the are present;
means that the element of the is not present, the element of the is present, and the contains exactly one occurrence of the element,
means that the element of the is not present, the element of the is present, and the contains exactly two occurrences of the element;
means that the element of the is not present, the element of the is present, and the contains exactly exactly three occurrences of the element;
means that the element of the is present, that the element specifies a number of aggregates that is four or greater, the element of the is present, and the contains exactly the number of occurrences of the element that the specifies.
::= ::= | | | | | | |
where:
means that neither the nor the elements of the are present;
means that the element of the is not present, the element of the is present, and the contains exactly one occurrence of the element,
means that the element of the is not present, the element of the is present, and the contains exactly two occurrences of the element;
means that the element of the is not present, the element of the is present, and the contains exactly exactly three occurrences of the element;
means that the element of the is not present, the element of the is present, and the contains exactly exactly four occurrences of the element;
means that the element of the is not present, the element of the is present, and the contains exactly exactly five occurrences of the element;
means that the element of the is not present, the element of the is present, and the contains exactly exactly six occurrences of the element;
means that the element of the is present, that the element specifies a number of aggregates that is seven or greater, the element of the is present, and the contains exactly the number of occurrences of the element that the specifies.
In addition to the above, we suggest the following text for the Part 2 specification of other elements in the object header. We take a more general approach to what is in the object header than the present text does since this seems to us a more logical way to do the specification:
::= *
::+ *********
The element specifies the offset in encoding-specific units from the element to the element:
::=
The element specifies the number of s in the :
::=
The element specifies the number of s in the :
::=
The element specifies the number of s in the :
::=
::= +
::= +
::= +
::=
::=
The follow text is provided to replace the corresponding text in the present Part 3:
6.2.3 Encoding of
The element is encoded as a BCE8_Unsigned.
6.2.4 Encoding of counts in the
The , , and element are each encoded as a BCE8_Unsigned.
6.2.5 Encoding of lists in the
The , ,