[closed] Re: Comments on xml:id PR

/ Dieter Köhler <d.k@philo.de> was heard to say:
| I have a few thoughts about what could possibly be improved or changed
| in the xml:id PR.

Thank you for your comments.

| 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.

The Core WG considered this comment but concluded that the word
"setting" here led to additional complications later in the document.
In an attempt to be responsive to your concerns, the editor suggests
the word "making" rather than changing or setting.

  [Definition: The process of ID type assignment causes an xml:id
  attribute value to be an ID.] This is often achieved by making the
  type of the attribute "ID" in the infoset or PSVI, but that is
  not the only possible mechanism.

| Sect. 2:
| "PSVI": For clarity, this abbreviation should perhaps be expanded and linked.

Accepted.

| 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.

The purpose of this note is to emphasize that the role of the xml:id
specification is to make sure that xml:id attributes have the correct
type. We leave actual processing of elements with a specific ID value
(and which ones, if any of those, can be addressed) to the application.
The Core WG has considered this comment and does not find the current
wording problematic.

| 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.

While we concede that your suggestion might be an improvement, we
observe that the word "assure" is used in many other places, including
the section on conformance. As a result, the XML Core WG is unwilling
to make the suggested change. (Removing the word assure globally seems
like too large a change to make at this time.)

| Sect. 4:
| "The xml:id processor performs ... the constraints."
| For clarity, change to:
| "The xml:id processor MAY perform ... the xml:id attributes constraints."

The sentence in question is not a MAY it is, if anything, a MUST.
An xml:id processor *DOES* perform ID type assignment on all xml:id
attributes, even those that do not satisfy the 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?

We believe that is already made clear by the sentence in question and
by the definition of id type assignment.

| 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".

Agreed.

| 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:

Agreed, implementation-dependent should be implementation-specific.

| "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."

The XML Core WG feels that the current sentence suitably expresses
the fact that there may or may not actually be any such structures.

| 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.

The XML Core WG has considered this comment and declines to make any
changes. We observe that at least one implementation is known to
perform xml:id processing in parallel with DTD and schema type
assignment. It is even possible to conceive of an application that
performs xml:id processing first and then DTD or Schema type
assignment after by using some technique to prevent subsequent
processing from overriding previous processing.

| 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.

The editor struggled to find the best possible order for the
information in these sections. It's possible that your suggestions
would be an improvement, but the XML Core WG is not inclined to make
such large scale changes at this point.

| Sect 5:
| "ID type assignment may": The word "may" should be linked.

The Core WG considered this comment and concluded that this paragraph
was confusing. We agreed to change it as follows:

<p>When ID type assignment
occurs, the <termref def="dt-xml-id-proc">xml:id processor</termref>
<termref def="dt-must">must</termref> report the assigned
<att>xml:id</att> attributes
to the application. How this is reported is implementation
dependent.</p>

| 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).

We considered this comment and decided upon the following change:

  The XML Recommendation requires parsers to ...

| 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.

We agreed to change "kinds" to "steps" to emphasize that these are two
steps in processing as described by the XML Rec. We also changed
"additional normalization" to "additional normalization steps".

We hope that these changes satisfy your concerns.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.