- From: Stef Busking <notifications@github.com>
- Date: Wed, 28 Jun 2017 06:49:07 -0700
- To: w3c/DOM-Parsing <DOM-Parsing@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Wednesday, 28 June 2017 13:49:39 UTC
If implemented as described in the specification, the algorithm to serialize an element's attributes (https://w3c.github.io/DOM-Parsing/#serializing-an-element-s-attributes) never preserves the prefix for any namespaced attribute that is not a namespace declaration: * Step 3.5: attributeNamespace is not null, run the sub-steps * Step 3.5.1: a candidate prefix is determined(*) * Step 3.5.2: attributeNamespace is not the XMLNS namespace, skip the sub-steps and continue with 3.5.3. * Step 3.5.3: interpreting the typo in "the attribute namespace in not the XMLNS namespace." as an assertion of the condition in 3.5.2 being false, run the sub-steps. * Step 3.5.3.1: the candidate prefix is overwritten by a generated prefix It seems that the candidate prefix generated in step 3.5.1 (marked (*)) is used in neither of the two branches. Am I correct in assuming that this is not the intended behavior? I would expect a new prefix to be generated only if the existing prefix conflicts with one associated with a different namespace in the local prefix map. This would require an extra check for candidate prefix being null afterwards, as the prefix may need to be redeclared (not regenerated) in that case. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/DOM-Parsing/issues/29
Received on Wednesday, 28 June 2017 13:49:39 UTC