ISO/IEC JTC 1/SC 32 WG2-EM0112-006

Date: 2001-12-11

REPLACES: -

Title: List of Ballot Comments for Continuation Editing Meeting on FCD 11179-3

Source: Ray Gates (Project Editor)

SEQ#	Cmnt ID	See Also	Severity	Reference	Description		Addressed By
020	AU31	GBR-P03-001 (#412)	1-Major Technical	P03-03	Each of the Editor’s Notes in Cl. 3. are supported by Australian stakeholders (ie. this is not just the former Editor’s opinion). For each component there must be a valid function that the component serves. An attribute (or attribute value etc. must have a function (serve a purpose) that its definition identifies. That definition must be immediately relevant to the reader as supporting the “area of interest” under discussion. While some of this can be deduced from the subsequent metamodel diagrams and explanation, it might be useful to compare the definitions and diagrams to identify instances where further explanation needs to be provided in the definition Proposed Solution Suggest the Editor’s Notes in Cl. 3 be implemented.		Deferred for review after specific comments have been addressed. Editor's Notes have been removed where there was a comment addressing them. All remaining Editor's Notes need discussion at the continuation editing meeting.
051	CAN-P03-016	CAN-P03-049 (#216) CAN-P03-085 (#293) CAN-P03-086 (#406)	4-Minor Editorial	P03-03-01-13	The Editor's Note on term "related metadata reference" needs to be addressed. The term uses the word “reference”, while the definition uses the word “relationship”. We should be more consistent. CAN-P03-049 (#216) proposes adding an “administered item relationship” to the model. This would seem to be a form of “related metadata reference”. However, in 11179-3:1994 “related data reference” supports references both within a single dictionary, and externally. How can we support external references? If we add an attribute to the model to explicitly support such references, the term and definition will need to be moved from 3.1 to 3.3. Proposed Solution For discussion at the editing meeting. At least make the term and definition consistent. [I.e. use either "reference" or "relationship" in both places.] The resolution of #216 (CAN-P03-049) has introduced a recursive relationship between administered items. This supports references within a registry. Possibly add an external metadata reference as an attribute. Delete the Editor's Note from clause 3.1.13 once it has been resolved.		For discussion at the CEM in conjunction with CAN-P03-049 (#216), CAN-P03-085 (#293), CAN-P03-086 (#406).
055	CAN-P03-116		2-Minor Technical	P03-03-02-03	The definition of “binding” is unsatisfactory. A mapping is not necessarily a binding, so what distinguishes a binding. A “Framework” is at one end of a range while “specification” is on the other. Can a binding really apply to both (and everything in between)? Further neither “framework” nor “specification” is defined in this standard, so it is difficult to know what is being bound. The definition of “binding” in IS 10032 (Data Management Reference Model) is: “A process which involves relating a process to specific data definitions”. This does not seem very satisfactory either. TR 14369:1999 defines “language binding” as: “A specification of the standard interface to a service, or set of services, for applications written in a particular programming language.” Proposed Solution Discussion at the editing meeting in Victoria led to the following proposal: Insert "An instantiation of" at the beginning of the definition, to give: "An instantiation of a mapping from one framework or specification to another."		To be discussed at the continuation editing meeting in context of clause 6. Check resolution of WG2-VIC-019D. We may not need the definition if all bindings are moved to ISO/IEC 20944.
062	CAN-P03-126	CAN-P03-133 (#299) S22-W11-013 (#063)	2-Minor Technical	P03-03-02-07	“Consume” implies “to use up” which is not applicable to information processing. The definition seems to better fit the term “parse”. However, CAN-P03-133 (#299) proposes replacing “consume and interpret” by “input”. Proposed Solution Delete clause 3.2.7.		Dependent on changes to clause 6.
063	S22-W11-013	CAN-P03-126 (#062)	4-Minor Editorial	P03-03-02-07	Subclause 3.2.7, page 5: Change the title of the definition "consume" ==> "consume (input data processing)".		Dependent on changes to clause 6.
072	CAN-P03-134	CAN-P03-133 (#299) S22-W11-017 (#073)	2-Minor Technical	P03-03-02-12	Delete use of the term “generate”, as proposed by CAN-P03-133 (#299). Proposed Solution Delete clause 3.2.12.		Dependent on changes to clause 6.
073	S22-W11-017	CAN-P03-134 (#072)	4-Minor Editorial	P03-03-02-12	Subclause 3.2.12, page 6: Change the title of the definition "generate" ==> "generate (output data processing)".		Dependent on changes to clause 6.
077	CAN-P03-132	CAN-P03-133 (#299) S22-W11-019 (#078)	2-Minor Technical	P03-03-02-14	Delete use of the term “interpret”, as proposed by CAN-P03-133 (#299). Proposed Solution Delete clause 3.2.14.		Dependent on changes to clause 6.
078	S22-W11-019	CAN-P03-132 (#077)	4-Minor Editorial	P03-03-02-14	Subclause 3.2.14, page 6: Change the title of the definition "interpret" ==> "interpret (input data processing)".		Dependent on changes to clause 6.
081	CAN-P03-155		2-Minor Technical	P03-03-02-17	“Metadata entry application” is defined, but clause 6 uses the term "metadata writer". Also, the current definition is incomplete because it does not allow for entry via electronic data interchange (EDI). Proposed Solution Pick one term and use it consistently. If text is added that uses the text, amend the definition to include reference to entry via data interchange. [Note: is it better to use the generic “data interchange” or should we restrict this to “electronic data interchange (EDI)” – in which case include the definition from ISO/IEC 14662.]		Dependent on changes to clause 6.
082	CAN-P03-138	CAN-P03-133 (#299)	2-Minor Technical	P03-03-02-18	Remove references to “consumption and interpretation” in accordance with CAN-P03-133 (#299). Proposed Solution Replace the definition by. “An application that inputs metadata.”		Dependent on changes to clause 6.
083	CAN-P03-139	CAN-P03-133 (#299)	2-Minor Technical	P03-03-02-18	Add a definition for “metadata writer application”. Proposed Solution metadata writer application “An application that outputs metadata.”		Dependent on changes to clause 6.
087	CAN-P03-161	CAN-P03-162 (#317) CAN-P03-163 (#320) S22-W11-022 (#088)	2-Minor Technical	P03-03-02-21	The term and definition are unclear. Also, the term actually used elsewhere in the document (6.1.3 and 6.1.4) is “smallest permitted maximum” Proposed Solution permitted maximum lower bound: A lower limit (specified by this Standard) on a maximum value that is to be specified by an implementation.		Dependent on changes to clause 6.
088	S22-W11-022	CAN-P03-161 (#087)	2-Minor Technical	P03-03-02-21	Subclause 3.2.21, page 6: Change the title of the definition "minimum-permitted maximum" ==> "smallest permitted maximum". Change the definition to: For implementation-defined values, the smallest permitted maximum value. Example: "The smallest permitted maximum string length of data element X shall be 17."		Dependent on changes to clause 6.
091	CAN-P03-135	CAN-P03-133 (#299) S22-W11-024 (#092)	2-Minor Technical	P03-03-02-23	Delete use of the term “produce”, as proposed by CAN-P03-133 (#299). Proposed Solution Delete clause 3.2.23.		Dependent on changes to clause 6.
092	S22-W11-024	CAN-P03-135 (#091)	4-Minor Editorial	P03-03-02-23	Subclause 3.2.23, page 7: Change the title of the definition "produce" ==> "produce (output data processing)".		Dependent on changes to clause 6.
095	CAN-P03-166		2-Minor Technical	P03-03-02-26	We assume that “shareable data” involves the sharing of data among two or more autonomous parties. If this is the requirement, then the current definition does not capture/support such concept/term. Proposed Solution Add following text to the end of the current definition: “as mutually agreed to among the parties sharing such data.”		Delete the term and its definition. Done. Consider addition of text to explain the concepts and implications of shareable data. The current definition is a list of constraints that shareable data must conform to. It is not a definition.
099	GBR-P03-004		1-Major Technical	P03-03-03	The Editor's Notes concerning datatype and related terms suggest that the reconciliation of the 11179-3 data model with that of 11404 needs further work. Proposed Solution UK is sympathetic to the quest for consistency with 11404, but does not have the technical knowledge of 11404 to be able to propose a solution.		Reconciliation with 11404 is deferred to a future version of this standard. Remove the editor’s notes. Return when other comments on this clause addressed.
107	CAN-P03-170		4-Minor Editorial	P03-03-03-005	In definition of “administrative status”, change “position” to “status” in definition. Rationale – a more appropriate term especially within the context of “life cycle”		See EDITOR’S NOTE in clause 3.3.8 of WG2-VIC-021.
120	CAN-P03-183		2-Minor Technical	P03-03-03-045 P03-03-03-046	It is not clear what would a “Data Element Example” or “data element example item” would consist of. Proposed Solution Provide examples of the examples.
160	CAN-P03-208	CAN-P03-009 (#016) S22-W11-031 (#161)	2-Minor Technical	P03-03-03-091	Add a normative reference to ISO/IEC 6523.		This was accepted in Victoria, but ISO/IEC 6523 does not define “organization mail address”. Was this accepted in error? Not done.
162	CAN-P03-209	CAN-P03-009 (#016)	2-Minor Technical	P03-03-03-092	Add a normative reference to ISO/IEC 6523.		This was accepted in Victoria, but ISO/IEC 6523 does not define "Organization name". Was this accepted in error? Not done.
197	CAN-P03-226	WG2-007 (#261a) WG2-008 (#275a) WG2-009 (#287a)	2-Minor Technical	P03-04	WG2 SD13 “Issue 081: Remove inappropriate aggregation symbols” needs to be addressed. [Note: This comment has been expanded from the original to include the proposals from the issue paper.] Proposed Solution The proposals from the issue paper are: 1. Convert the associations: "data element concept conceptual domain" and "data element representation" from aggregations to simple associations. (Already done in FCD.) 2. Convert the associations: "permissible value meaning" and "permitted value" from aggregations to simple associations. (Already done in FCD.) 3. Further, the "comprised of" labels on the above associations need changing. While an enumerated domain is comprised of (or contains) a set of permitted values, a "permissible value" is not comprised of a value meaning and a value, but rather associates a value meaning with a value within a particular domain. Suggest using the labels: · A Permissible Value "represents" (or possibly just "has") a Value Meaning · A Permissible Value "uses" a Value 4. The aggregation symbol on "derivation input" (Figures 7 and 8) is probably no longer appropriate, since the class "Data Element Derivation" (previously "Input Set") is more than a collection of inputs. It is there to establish the three-way association among inputs, rule and output. 5. The relationship between Registration Authority and Registrar is shown as an aggregation (Figure 2). Since Registration Authority is a subtype of Organization, it is more than a collection of registrars. The labels should be something like "employing" and "employed by" rather than "containing" and "included in", and the aggregation symbol should be removed.		Proposals 1 and 2 previously done. Proposal 5 done by #222. Separate comments created for proposals 3 and 4. See WG2-007 (#261a), WG2-008 (#275a) , WG2-009 (#287a). No action here. Included here only as background for 261a, 275a and 287a.
198	CAN-P03-227		2-Minor Technical	P03-04	WG2 SD13 “Issue 098: Scope of name spaces” needs to be addressed. [Note: This comment has been expanded from the original to include details from the issue paper, and to add a proposed solution.] The last paragraph of Clause 4.6.1 states: "A particular name must be unique for a particular language within a given context and across all types of administered component. For example, a data element and a value domain may not both have the same name within a particular context in any one language. Either, suitable qualifiers should be added to names to make them unique, or if that is not possible the definitions of context need to be refined to allow the use of distinct contexts." This text was introduced by the resolution of CD ballot comment CAN-P03-069. Issues: Should name spaces be modeled explicitly? Does the quoted paragraph adequately define the name spaces we need? Do we need to provide registrars the capability to define their own name spaces? Proposed Solution The issue paper proposes: "Review the scope within which names must be unique. Consider providing some flexibility to registrars to set their own rules." NOTE: ISO/IEC 11179-5 clause 4.2 explicitly states a naming convention for a Context shall specify whether or not names are required to be unique within the context. Proposal 1: Add to Context a new attribute: "context_names_unique [0..1] : Boolean". Update Figure 3 and clause 4.6.2. Proposal 2: Add to Context a new attribute: "context_naming_convention_description [0..1] : string" to allow the naming convention for the context to be described or referenced. Update Figure 3 and clause 4.6.2.
198a	WG2-003	CAN-P03-181 (#116)	2-Minor Technical	P03-04	Implement resolution of CAN-P03-181 (#116) in clause 4.		Add a sub-clause in clause 4 on the use of dates, and reference 8601. Draft text provided in WG2-VIC-020 and revised in WG2-EM0112-007.
207	S22-W11-038	AU01 (#009)	4-Minor Editorial	P03-04-03	Subclause 4.3, page 28: Better wording should be provided to explain extensibility. I will try to extract some words from IEEE 1484.14.1, Data Extension Techniques.		Defer unless proposal available. To address 009, change: “For example, scientific data” to “Particular sectors, such as document management, scientific data, statistical data….” Done.
209	CAN-P03-213	AU44 (#210)	4-Minor Editorial	P03-04-04	In the first sentence, the reference to Figure 2 should be to Figure 1. Also, it would be useful to explicitly list the key elements of the Figure. Proposed Solution Replace the first sentence by: For descriptive purposes, the metamodel is divided into six functional regions, namely, > Administration and Identification > Naming and Definition > Classification > Data Element > Data Element Concept; and. > Conceptual and Value Domain. Figure 1 presents an illustration of these Metamodel regions. Insert a paragraph break before the sentence: “The primary region is…”.		Accepted. Needs to be reconciled with new Figure developed as resolution of AU44 (#210). Proposed revision provided as WG2-VIC-024R1 during the editing meeting. The editor has since produced WG2-VIC-024R2 for discussion at the continuation editing meeting. Proposal from WG2-VIC-024R2 has been incorporated.
211	S22-W11-040		1-Major Technical	P03-04-05 P03-04-06 P03-04-07 P03-04-08 P03-04-09 P03-04-10 P03-04-11		Subclauses 4.5-4.11, pages 30-49" This subclause should be rearranged as a set of datatypes and nested definitions. For example, in C-like notation (probably should use 11404 notation): typedef struct { item_identifier_type item_identifier; string registration_status; string administrative_status; date_time creation_date; date_time last_change_date; // May be null date_time effective_date; // May be null date_time until_date; // May be null string change_description; string adminsitrative_note; string explanatory_comment; string unresolved_issue; string origin; registration_authority_type registration; organization_type submitted_by; organization_type administered_by; reference_document_type described_by; } administration_record_type; typedef struct { item_registration_authority_identifier_type registation_authority_identifier; string data_identifier; string version; } item_identifier_type; // and so on ... The standards wording for each "region" would describe the meanings and value spaces of each of these components (e.g., creation_date). The UML notation should *not* be used normatively. The problem with UML notation is that it is not clear, from a standards interperations perspective, what assertions are being made in the UML notation. The UML notation should be informative. The above "structure-like" notation should be normative.		Replacement of UML by 11404 notation not accepted. Make Organization sub-ordinate to other classes. Editor’s response: What exactly was intended here?
213a	WG2-006	CAN-P03-226 (#197)	2-Minor Technical	P03-04-05		Apply resolution of CAN-P03-226 (#197) proposal 5 to Figure 2 in clause 4.5.
230	CAN-P03-199	CAN-P03-198 (#153)	2-Minor Technical	P03-04-06		Apply CAN-P03-198 (#153) to Figure 3 in clause 4.6.		Defer to continuation editing meeting.
241a	WG2-004		2-Minor Technical	P03-04-06-01		Discussion of part 5 caused some US delegates to raise concerns about the requirement in 4.6.1 that names be unique within a context. Part 5 requires a registrar to specify whether or note a name is unique. Proposed Solution Add an attribute to Context, "names unique within context: True_False ". Add the attribute to clause 4.6.2. Replace the first sentence in para 3 of clause 4.6.1, as follows: "A registrar shall specify whether names within a particular context must be unique. When this constraint is true, a particular name must be unique for a particular language within the given context and across all types of administered items."		Not yet discussed.
256	JPN-004	JPN-005 (#176)	2-Minor Technical	P03-04-08-02		- 4.8.2 Property(page41) & Figure5(page.40) In this section, according to the explanation of 'property', a property is a characteristic of an object class. However, in the metamodel diagram(Figure 5), 'Property' is just a (meta)attribute of the 'Data_Element_Concept', not a (meta)attribute of 'Object_Class'. So, if the diagram is right, Object_Class cannot have a 'property' directly. Threfore, it seems that there are some inconsistency between the explanation and the diagram. (It might be possible to say that "an Object_Class may have a relation to 'a property' through a Data_Element_Concept" because Data_Element_Concept also have an attribute 'data_element_concept_object', ,and throught this attribute, an Object_Class and a 'property' may have a relationship. However, even so, it seems unnatural to say that an Object_Class HAVE a 'property'.)		Doug to discuss concerns with Horiuchi-san.
261a	WG2-007	CAN-P03-226 (#197) WG2-009 (#287a)	2-Minor Technical	P03-04-09		Apply resolution of CAN-P03-226 (#197) proposal 3 to Figure 6 in clause 4.9.
275a	WG2-008	CAN-P03-226 (#197) WG2-009 (#287a)	2-Minor Technical	P03-04-10		Apply resolution of CAN-P03-226 (#197) proposal 4 to Figure 7 in clause 4.10.
287a	WG2-009	CAN-P03-226 (#197) WG2-007 (#261a) WG2-008 (#275a)	2-Minor Technical	P03-04-11-01		Apply resolution of CAN-P03-226 (#197) proposals 3 and 4 to Figure 8 in clause 4.11.1.
288	CAN-P03-220		1-Major Technical	P03-05		At present there seems to be a single level of conformance. We probably need at least two levels, one for users who want only the old Basic Attributes, and another for users who want a registry metamodel. We should also consider if there are opportunities to subset the metamodel, and provide multiple levels of conformance. Proposed Solution To be provided.		Consider in the context of the revision to clause 6.
293	CAN-P03-085	CAN-P03-016 (#051) CAN-P03-049 (#216) CAN-P03-086 (#406)	2-Minor Technical	P03-05-02-04		This clause uses the term "related metadata reference", but such generic references are not supported by the model. Proposed Solution To be provided.		To be discussed at the CEM in conjunction with CAN-P03-016 (#051), CAN-P03-049 (#216), CAN-P03-086 (#406)
299	CAN-P03-133	CAN-P03-126 (#062) CAN-P03-127 (#330) CAN-P03-131 (#337) CAN-P03-132 (#077) CAN-P03-134 (#072) CAN-P03-135 (#091) CAN-P03-136 (#349) CAN-P03-137 (#350) CAN-P03-138 (#082) CAN-P03-139 (#083) CAN-P03-140 (#316) CAN-P03-141 (#319) CAN-P03-142 (#303) CAN-P03-143 (#321) CAN-P03-144 (#322) CAN-P03-145 (#338) CAN-P03-146 (#339) CAN-P03-147 (#340) CAN-P03-148 (#345) CAN-P03-149 (#323) CAN-P03-150 (#324)	1-Major Technical	P03-06		The details of parsing, interpreting, generating and producing metadata are internal to an implementation. This is a level of detail that is not required in this standard whose scope is the registry metamodel. If these concepts are required by the Metadata Access Service (MDAS), they should be specified in that standard. Proposed Solution General solution: 1) Replace the dual notion of “consume and interpret” by the single notion of “input”. 2) Replace the dual notion of “generate and produce” by the single notion of “output”. Specifically, in the Rational in clause 6, para. 2, replace “generate” by “output” and “interpret” by “input”. See cross-referenced comments for detailed text changes to other clauses and sub-clauses.		At the Victoria meeting, the UK developed three proposals: WG2-VIC-019, WG2-VIC-019B, WG2-VIC-019C. Frank Farance was to take these contributions and produce a fourth version for the continuation editing meeting. Defer to continuation editing meeting.
300	CAN-P03-223		1-Major Technical	P03-06		Clause 6 needs a detailed review to ensure that it is consistent with the rest of the document. Proposed Solution To be provided.		Defer to continuation editing meeting.
301	GBR-P03-005		1-Major Technical	P03-06		Clause 6 still contains a lot of Editor's Notes and a lot of Rationale sections. It is also long and difficult to follow, partly because it caters for conformance in areas (API and protocol) not covered by this version of the standard. While all the current material needs to be filed carefully in case it is needed in a future version, the clause needs to be slimmed down to what is actually necessary for the current content of Part 3. Clause 6 is also difficult to follow because it has so few references to other clauses of the standard. For example, clause 6.6.5 condition 6 says in part "strictly conform to at least one MdR3 coding binding and at least one MdR3 API or MdR3 protocol binding", but there are no clause references to where such bindings can be found. Proposed Solution No overall solution is offered, but possible solutions to individual problem areas are given with the more detailed comments that follow.		Defer to continuation editing meeting.
302	CAN-P03-099		2-Minor Technical	P03-06		Complete review of clause 6. Proposed Solution To be provided.		Defer to continuation editing meeting.
303	CAN-P03-142	CAN-P03-001 (#002)	2-Minor Technical	P03-06		Change all instances of “MdR3” to “MdR” in accordance with CAN-P03-001 (#002) proposal 5.		Defer to continuation editing meeting.
304	CAN-P03-197	CAN-P03-046 (#208)	2-Minor Technical	P03-06		Incorporate CAN-P03-046 in clause 6.		Defer to continuation editing meeting.
305	S22-W11-041		3-Major Editorial	P03-06		Clause 6, pages 55-65: The conformance clause should be before all the assertions, i.e., the conformance clause should be Clause 4.		Defer to continuation editing meeting.
306	GBR-P03-013		1-Major Technical	P03-06 No specific location		The current version of Part 3 has no protocol or API defined. Though it will be helpful in the future for those revising the standard to know how they could be added to clause 6, that is not sufficient justification for leaving references to them in the published version of clause 6. Proposed Solution Remove all clauses and subclauses that refer to API or protocol, and all other references to them. Specifically, remove: References to API and protocol in 6.1.3 and 6.1.4; References within examples in 6.2 to an API or protocol; Subclauses 6.2.11 to 6.2.16; Subclauses 6.4 and 6.5; References to APIs and protocols in clause 6.6.		Defer to continuation editing meeting.
307	GBR-P03-011		2-Minor Technical	P03-06 No specific location		The three terms "binding", "coding", and "encoding" are all used within this clause, but the relationship between them is not clear. Of them, only binding is defined in clause 3.2, and the definition given there is too general to be helpful in the context of clause 6. Outside clause 6, encoding is used only in Annex E, coding only in the conformance-related definitions of produce and consume in 3.2, and binding only in its own definition in 3.2. Proposed Solution If, as seems to be intended, encoding and coding have the same meaning, use just one of them, consistently. Make the definition of binding in 3.2 appropriate to its use in clause 6.		Defer to continuation editing meeting.
308	GBR-P03-018	GBR-P03-007 (#313)	2-Minor Technical	P03-06 No specific location		It is stated in 6.6.2 that when extensions are used, behaviour is implementation-defined. The implementer should be required to provide definitions of such behaviour. Proposed Solution Amend existing text, and/or add new text, to indicate that when extensions are used, behaviour is implementation-defined, and that the ICS shall define such behaviour.		Defer to continuation editing meeting.
310	GBR-P03-010		2-Minor Technical	P03-06.01.02		The text in 6.1.2 (Rationale) is useful explanation at this point in the clause, but should be given a more meaningful heading. The text of the notes in clause 6.6.1 and 6.6.2 probably belongs here also, since it provides a clearer justification for the distinction. Proposed Solution Change heading 6.1.2 to read "6.1.2 Levels of conformance". Add the following text (from the notes in 6.6.1 and 6.6.2) to the end of 6.1.2: "A strictly conforming implementation may be limited in usefulness but is maximally interoperable with respect to this Standard. A conforming implementation may be more useful, but may be less interoperable with respect to this Standard.		Defer to continuation editing meeting.
311	GBR-P03-019		2-Minor Technical	P03-06.No specific location		In the context of a metadata application, it is not clear that the distinction between "consume" and "interpret", or between "produce" and "generate", is helpful in the context of this standard. Since it creates what appears to be an unnecessary complication, the distinction should be removed unless it can be justified. Proposed Solution Remove this distinction, and the associated definitions and explanations. Replace the first sentence of 6.6.6, down to the end of the note reading " ... phases of processing.", with the following: "A metadata reader is a metadata application that interprets metadata and creates metadata sets." Replace the first sentence of 6.6.7, down to the end of the note reading " ... phases of processing.", with the following: "A metadata writer is a metadata application that accepts metadata sets as input and produces metadata."		Defer to continuation editing meeting.
312	GBR-P03-006		2-Minor Technical	P03-06-00		The Rationale, and most of the other text preceding clause 6.1, adds little to understanding of the standard. Proposed Solution Replace the whole of the unnumbered text in clause 6 (before clause 6.1) by the following: "The behaviour of an implementation is undefined whenever any of the following occurs: 1) a requirement of the standard (expressed by "shall") is not met; 2) a prohibition of the standard (expressed by "shall not") is violated; 3) behaviour is not explicitly defined in the standard."		Defer to continuation editing meeting.
313	GBR-P03-007		2-Minor Technical	P03-06-00		An Implementation Conformance Statement is mentioned in Note 2, but there seems to be no stated requirement that an implementation shall supply one. Proposed Solution Add such a requirement within 6.1: "6.1.n Implementation Conformance Statement (ICS) An implementation claiming conformance to this standard shall include an Implementation Conformance Statement stating, using the terms in clause 6.2 below, the types of conformance claimed."		Defer to continuation editing meeting.
314	GBR-P03-008		2-Minor Technical	P03-06-01		The text at the start of 6.1 says that the terms test, access and probe are defined in clauses 6.3, 6.4, 6.5 and 6.6. Clauses 6.4 and 6.5 are moot, since the standard contains no API or protocol, and a later comment will therefore propose removing them from this version. Clause 6.3 states that those three terms are not relevant to encoding conformance, and clause 6.6 does not seem to contain definitions of these terms in the context of an application. Further, the terms support and use are used within clause 6 only in their normal sense. Proposed Solution Delete the text between headings 6.1 and 6.1.1, and remove any other references to the terms test, access and probe where the meanings are not both relevant and self-explanatory.		Defer to continuation editing meeting.
315	GBR-P03-009		2-Minor Technical	P03-06-01-01		It is not clear how the role of registration authorities can or should affect conformance with Part 3. The text of 6.1.1 (Caveat) appears to address interoperability, not conformance. Proposed Solution Delete clause 6.1.1.		Defer to continuation editing meeting.
316	CAN-P03-140	CAN-P03-133 (#299)	2-Minor Technical	P03-06-01-03		Remove references to “interpret” and “generate” in accordance with CAN-P03-133 (#299). Proposed Solution In para 2, item 4, replace “interpret or generate” by “input or output”.		Defer to continuation editing meeting.
317	CAN-P03-162	CAN-P03-161 (#087)	2-Minor Technical	P03-06-01-03		Apply the resolution of CAN-P03-161 (#087) to clause 6.1.3.		Defer to continuation editing meeting.
318	CAN-P03-164	CAN-P03-163 (#320)	1-Major Technical	P03-06-01-04		The clause states that a “conforming implementation” may: “exceed limits or smallest permitted maximum values specified by this Standard”. Permitting an implementation to set a smaller maximum value than the smallest specified by the standard could result in the implementation being unable to support data from a strictly conforming implementation. This should not be permitted. Proposed Solution Replace “or smallest permitted maximum values” by “(excluding smallest permitted maximum values)”		Defer to continuation editing meeting.
319	CAN-P03-141	CAN-P03-133 (#299)	2-Minor Technical	P03-06-01-04		Remove references to “interpret” and “generate” in accordance with CAN-P03-133 (#299). Proposed Solution In para 2, item 5, replace “interpret or generate” by “input or output”.		Defer to continuation editing meeting.
320	CAN-P03-163	CAN-P03-161 (#087) CAN-P03-164 (#318)	2-Minor Technical	P03-06-01-04		Apply the resolution of CAN-P03-161 to clause 6.1.4.		Defer to continuation editing meeting.
321	CAN-P03-143	CAN-P03-133 (#299)	2-Minor Technical	P03-06-02-07		Remove references to “interpreted” in accordance with CAN-P03-133 (#299). Proposed Solution Replace two instances of “interpreted” by “inputted”.		Defer to continuation editing meeting.
322	CAN-P03-144	CAN-P03-133 (#299)	2-Minor Technical	P03-06-02-08		Remove references to “interpreted” in accordance with CAN-P03-133 (#299). Proposed Solution Replace two instances of “interpreted” by “inputted”.		Defer to continuation editing meeting.
323	CAN-P03-149	CAN-P03-133 (#299)	2-Minor Technical	P03-06-02-09		Remove references to “generate” in accordance with CAN-P03-133 (#299). Proposed Solution Replace three instances of “generate” by “output”.		Defer to continuation editing meeting.
324	CAN-P03-150	CAN-P03-133 (#299)	2-Minor Technical	P03-06-02-10		Remove references to “generate” in accordance with CAN-P03-133 (#299). Proposed Solution Replace three instances of “generate” by “output”.		Defer to continuation editing meeting.
325	CAN-P03-158		2-Minor Technical	P03-06-03-02		In the Rationale, the reference to metadata register should be to metadata registry.		Defer to continuation editing meeting.
326	GBR-P03-014		2-Minor Technical	P03-06-03-02		Note 1 of 6.3.2 refers to a paragraph that no longer seems to exist. Should it be restored? Proposed Solution Remove the note, or restore the text it refers to.		Defer to continuation editing meeting.
327	GBR-P03-015		2-Minor Technical	P03-06-03-02		Note 2 of 6.3.2 refers to a "strictly conforming/conforming coding", but this concept has not been defined in clause 6.2. The second point of Note 2 of 6.3.2 does not seem to be relevant in this context. If it is, the wording needs to be improved to make its relevance clear. Proposed Solution Remove or reword note 2.		Defer to continuation editing meeting.
328	GBR-P03-016	GBR-P03-008 (#314)	2-Minor Technical	P03-06-03-02		The two sets of definitions following 6.3.2 are probably redundant. Proposed Solution Remove the two paragraphs headed Definitions unless they add something important and different from common usage.		Defer to continuation editing meeting.
329	GBR-P03-017		2-Minor Technical	P03-06-03-02		The last paragraph of text (Rationale) is useful explanatory material, but should appear earlier. Proposed Solution Move this paragraph, without its heading, to appear between headings 6.3 and 6.3.1.		Defer to continuation editing meeting.
330	CAN-P03-127	CAN-P03-133 (#299)	2-Minor Technical	P03-06-06-01		Delete use of the term “consume”, as proposed by CAN-P03-133 (#299). Proposed Solution In the third bullet, end the sentence at “within an implementation.” Delete “see the definition of consume” and the rest of the sentence.		Defer to continuation editing meeting.
331	GBR-P03-020	GBR-P03-019 (#311)	2-Minor Technical	P03-06-06-01		The third point in 6.6.1, beginning "Extended features", contains a note that confuses more than it clarifies, and that refers to the definition of "consume" in 3.2, which definition also contains no clarification. Proposed Solution If this is not resolved by the solution to GBR-P03-019 (#311), remove this note or amend it to make clearly whatever point it is intended to make.		Defer to continuation editing meeting.
332	GBR-P03-021	GBR-P03-010 (#310)	2-Minor Technical	P03-06-06-01		It was proposed in GBR-P03-010 (#310) to move the first sentence of the Note to clause 6.1.2. The remaining text in the note seems to add nothing to what has already been said. Proposed Solution Delete the note at the end of 6.6.1.		Defer to continuation editing meeting.
333	GBR-P03-022	GBR-P03-010 (#310)	2-Minor Technical	P03-06-06-02		It was proposed in GBR-P03-010 (#310) to move the first sentence of the Note to clause 6.1.2. The remaining text in the note seems to add nothing to what has already been said. Proposed Solution Delete the note at the end of 6.6.2.		Defer to continuation editing meeting.
334	GBR-P03-023		2-Minor Technical	P03-06-06-03		The text in 6.6.3 is confusing and contradictory. First example: the suggestion in 6.6.3.2 that an implementation can be strictly conforming but support extensions seems to be in direct conflict with clause 6.2.5, 6.2.7 and 6.2.9. Second example: The second sentence describing example 1 reads "When metadata is stored into and retrieved from P, P uses a particular binding metadata that metadata extensions are permitted to be ignored, e.g., as a coding binding that uses "extension prefixes", an API binding that "hides implementation details", or a protocol that uses "fallback negotiation and out-of-band messages"."; this sentence cannot be parsed, and uses terms that have not been defined. Proposed Solution Delete the whole of 6.6.3 unless it can be both justified and clarified.		Defer to continuation editing meeting.
335	CAN-P03-129		2-Minor Technical	P03-06-06-03-02		Para. 1 sentence 3 states that the examples use “metadata registers” when in fact they refer to “metadata registries”. Proposed Solution Change “registers” to “registries”.		Defer to continuation editing meeting.
336	CAN-P03-130		2-Minor Technical	P03-06-06-03-02		Example 1, sentence 2 does not read well: “When metadata is stored into and retrieved from P, P uses a particular binding metadata that metadata extensions are permitted to be ignored.” Proposed Solution Reword as: “When metadata is stored into and retrieved from P, P uses a binding that allows metadata extensions to be ignored.”		Defer to continuation editing meeting.
337	CAN-P03-131	CAN-P03-133 (#299)	2-Minor Technical	P03-06-06-03-02		In Example 1 delete use of the term “consume”, as proposed by CAN-P03-133 (#299). Proposed Solution In sentences 3 and 4, replace “consume and interpret” by “input”. In sentence 5, replace “generates and produces” by “outputs”. In the last sentence, item (3) replace “generate and interpret” by “output and/or input”.		Defer to continuation editing meeting.
338	CAN-P03-145	CAN-P03-133 (#299)	2-Minor Technical	P03-06-06-03-02		In the first sentence, remove references to “generator and interpreter” in accordance with CAN-P03-133 (#299). Proposed Solution Replace “generator and/or interpreter” by “writer and/or reader”.		Defer to continuation editing meeting.
339	CAN-P03-146	CAN-P03-133 (#299)	2-Minor Technical	P03-06-06-03-02		In Example 2, second sentence, remove references to “consuming, interpreting, generating, and producing” in accordance with CAN-P03-133 (#299). Proposed Solution Replace “consuming, interpreting, generating, and producing” by “inputting and outputting”.		Defer to continuation editing meeting.
340	CAN-P03-147	CAN-P03-133 (#299)	2-Minor Technical	P03-06-06-03-02		In Example 2, last sentence, remove references to “generate” and “interpret” in accordance with CAN-P03-133 (#299). Proposed Solution Replace “generated and interpret” by “input and output”.		Defer to continuation editing meeting.
342	CAN-P03-159		2-Minor Technical	P03-06-06-04		In the Rationale, “or metadata registers” should be “of metadata registries”.		Defer to continuation editing meeting.
343	GBR-P03-024	GBR-P03-025 (#344)	2-Minor Technical	P03-06-06-04		The first sentence in 6.6.4 would be more helpful if it appeared earlier, either before 6.6.1 or even before 6.1. The first sentence of 6.6.5/6/7 would also be better placed earlier. Proposed Solution Move the first sentence of each of 6.6.4, 6.6.5, 6.6.6 and 6.6.7 to form a new paragraph immediately before heading 6.6.1.		Defer to continuation editing meeting.
344	GBR-P03-025	GBR-P03-024 (#343)	2-Minor Technical	P03-06-06-04		The text below Rationale in 6.6.4 does not add anything to the standard, particularly in the light of the change proposed in GBR-P03-024. Proposed Solution Delete the heading Rationale and the associated text in 6.6.4. If GBR-P03-024 was accepted, heading 6.6.4 will now have no text, in which case remove the heading and renumber.		Defer to continuation editing meeting.
345	CAN-P03-148	CAN-P03-133 (#299)	2-Minor Technical	P03-06-06-05		Remove references to “interpretation” and “generation” in accordance with CAN-P03-133 (#299). Proposed Solution In the description of a strictly conforming metadata registry: Replace item 2) by: “Use strictly conforming metadata readers for inputting metadata sets;” Replace item 5) by: “Use strictly conforming metadata writers for outputting metadata sets;” In the description of a conforming metadata registry: Replace item 2) by: “Use conforming metadata readers for inputting metadata sets;” Replace item 5) by: “Use conforming metadata writers for outputting metadata sets;”		Defer to continuation editing meeting.
346	CAN-P03-160		2-Minor Technical	P03-06-06-05		The last sentence of Note 1 refers to “strictly conforming metadata registers” but clause 6.2 does not include “strictly conforming metadata register” as a valid conformance label. Should “registers” be “registries” or do we need to specifiy conformance for registers independent of registries? Proposed Solution For discussion at editing meeting.		Defer to continuation editing meeting.
347	GBR-P03-026		2-Minor Technical	P03-06-06-05		Note 1 conflicts with item 3 in the "shall" list. We need to decide clearly, once and for all times and contexts, what a strictly-conforming implementation does with extensions. My understanding is that point 3 is correct, so that passing metadata that includes extensions through a strictly-conforming registry is guaranteed to remove the extensions. Proposed Solution Remove the last part of Note 1, from "But does not prohibit...".		Defer to continuation editing meeting.
348	GBR-P03-027		2-Minor Technical	P03-06-06-05		Note 3 seems rather vague. Would it not be better to require that the Implementation Conformance Statement say what extensions are supported? Proposed Solution Amend note 3 to read: "A conforming metadata registry may store some metadata extensions, but it is not required to store and retrieve all metadata extensions. The Implementation Conformance Statement shall state which extensions are supported."		Australia suggests replacing “which extensions” by “any extensions that”. Defer to continuation editing meeting.
349	CAN-P03-136	CAN-P03-133 (#299)	2-Minor Technical	P03-06-06-06		The description of a metadata reader provides more detail than is required for this standard. (See CAN-P03-133 (#299).) Proposed Solution 1) Replace the first paragraph, including the two list items and Note 1 by: “A metadata reader is a metadata application that inputs metadata.” 2) In the paragraph following Note 1, change “interpret” to “input”. 3) In Note 2, change “does not interpret” to “ignores”. Renumber the Note as 1. 4) Delete Note 3. 5) In the sentence following Note 3, change “interpret” to “input”. 6) In Note 4, change “interpret” to “input”. Renumber the Note as 2.		Defer to continuation editing meeting.
350	CAN-P03-137	CAN-P03-133 (#299)	2-Minor Technical	P03-06-06-07		The description of a metadata writer provides more detail than is required for this standard. (See CAN-P03-133 (#299).) Proposed Solution 1) Replace the first paragraph, including the two list items and Note 1 by: “A metadata writer is a metadata application that outputs metadata.” 2) In the sentence following Note 1, replace “generate” by “output” 3) In Note 2, replace “generate” by “output”. 4) Renumber Note 2 as Note 1. 5) In the sentence following Note 2, replace “generate” by “output” 6) In Note 3, replace “generate” by “output”. Renumber the Note as 1. 7) Renumber Note 3 as Note 2.		Defer to continuation editing meeting.
351	S22-W11-001		4-Minor Editorial	P03-0-General		Change all "MdR" ==> "MDR".		Comment from Graham Horn: This would be bad English. "Meta" is not a word on its own. It is a prefix that doesn't take a hyphen for any word in the English language (check a dictionary, eg. metanalysis, metaphysics, metastasis, etc.). Proper Acronyms only take upper case for letters that are first letters of words (if then), and the "d" isn't one of these. If the "d" is needed, it should be lower case.
365	MN-005		4-Minor Editorial	P03-All P03-04-06-01		There is inconsistent treatment of the concepts of "designation" and "name". In general throughout the document, they are intentionally or accidentally treated as equivalent; an obvious one is in Clause 4.6.1 paragraph 2, "Designation (name)." However, the definitions at the beginning appear to indicate a desire to make them quite different concepts, which I agree may have some value. Please clarify or remove the difference and make it consistent. Proposed Solution In 4.6.1, paragraph 2, sentence 1: Change “Designation (name)” to “Designation (e.g., name)”		Accepted. Editor's response. Why what this accepted? What can a designation be (in this standard) other than a name?