- From: Dieter Köhler <d.k@philo.de>
- Date: Wed, 13 Jul 2005 17:29:23 +0200
- To: public-xml-id@w3.org
I have a few thoughts about what could possibly be improved or changed in the xml:id PR. Sect. 2: "This is often achieved by changing ..." should be modified to: "This is often achieved by setting ..." Reason: "Changing" implies that some sort of type assignment has been done before, but sect. 4 says that its application-dependent when xml:id processing occurs. The term "setting" is neutral. Sect. 2: "PSVI": For clarity, this abbreviation should perhaps be expanded and linked. Sect. 2: "Application-level processing of IDs, including which elements can actually be addressed by which ID values, is beyond the scope of this specification" This sentence is problematic, because sec. 4 refers to the infoset [references] property, which is used to determine the elements which are actually addressed by an ID value. Sect. 4: "An xml:id processor must assure ...", "An xml:id processor should assure ...", "An xml:id error occurs for any xml:id attribute that does not satisfy the constrains." The implication of the last sentence seems to be that an xml:id error occurs only for those unsatisfied constrains that the processor assures, right? Therefore, I would suggest clarifying this be replacing the "assure"-sentences with: "An xml:id error MUST occur for any xml:id attribute that does not satisfy the following constrains:" and "An xml:id error SHOULD occur for any xml:id attribute that does not satisfy the following constrain:" The sentence "An xml:id error occurs for any xml:id attribute that does not satisfy the constrains." can then be omitted. Sect. 4: "The xml:id processor performs ... the constraints." For clarity, change to: "The xml:id processor MAY perform ... the xml:id attributes constraints." What happens if a type conflict occurs? Shouldn't it be explicitly stated that xml:id type assignment takes precedence over DTD and Schema type assignments? Sect. 4: "An xml:id processor should update the [references] infoset property, as described in Section 2.3 of [XML Information Set], and update any implementation-dependent structures used for cross-referencing to reflect the results of ID assignment." For consistency, the sequence "[references] infoset property" should be changed to "infoset [references] property". The term "implementation-dependant" is a bit irritating to me, because the spec does not explicitly describe a choice of certain "implementation-dependant" functionalities. The word "implementation-specific" together with "if any" clarifies this: "An xml:id processor should update the infoset [references] property, as described in Section 2.3 of [XML Information Set] and update other implementation-specific structures used for cross-referencing, if any, to reflect the results of ID assignment." Sect 4: "... it is up to the application to determine when such processing occurs." If xml:id type assignment takes precedence over DTD and Schema type assignments (see above), then xml:id processing naturally MUST occur after DTD and Schema type assignment. Sect 4 and 5: The section divisions and the sequence of appears to me to be somewhat problematic. "Processing xml:id Attributes" and "Informing the Application" are not two distinct steps (informing the application is rather a part of xml:id processing). This can also be seen by the repetitions such as "The xml:id processor performs ID type assignment ..." (sect. 4) and "ID type assignment may be performed when ..." (sect. 5). In fact all sentences in sect. 4 starting with "The xml:id processor performs ..." would IMHO fit better at the end of sect. 5, after the standard process of ID type assignment has been described. In other words, my suggestion is to completely remove the section heading "5 Informing the Application" and shift the contents of this section to the middle of section 4, behind the part that deals with the constraints. Sect 5: "ID type assignment may": The word "may" should be linked. App. E: "Parser are required to normalize all attribute values." change to: "Parser are required to normalize all attribute literal values." This modification clarifies, that no nested normalization must take place, with a normalized attribute value from a previous validation operation (this might by relevant only if the normalized attribute value does not conform to NCName, though). App. E: "The xml:id processor has to assure that both kinds of normalization are performed all attributes named xml:id." change to: "The xml:id processor has to assure that complete ID value normalization is performed on all attributes named xml:id." Reasons: - The XML spec does not distinguish between two different kinds of normalization, but calls the second step a "further processing" when normalizing. - missing "on". APP. E: "additional normalization(s)" (several occurrences) change to "complete ID value normalization" Reasons: see above. Dieter Köhler
Received on Wednesday, 13 July 2005 15:39:07 UTC