Comments on xml:id PR

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