[Bug 24208] Please handle the case of XML attributes with namespaces but no prefix

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24208

--- Comment #4 from Travis Leithead [MSFT] <travil@microsoft.com> ---
(In reply to Victor Costan from comment #3)
> I have a slight preference for lowercase "ns" as well, and that's what my
> work-in-progress patch uses for Blink. I'm willing to implement what you end
> up spec'ing though.

Cool, I'll go with "ns" then as a prefix...

> FWIW, in my implementation, I'm not using sequential indices. Instead, the
> indices are based on an internal hash function. If the specification
> mandates sequential indices, I hope that it will do so in a way that does
> not require a quadratic-time algorithm. For bonus points, try not adding any
> memory overhead for DOMs that set their own prefixes for attributes with
> namespaces.

So, your indexes will be random? How many digits will you use to represent the
result of the hash? 

Given a local incrementing counter approach, two unique serializations of
different parts of a DOM are at risk of defining the same prefixes for
different namespaces. I'm not sure that's a problem unless you end up wanting
to combine these serialized strings together (in which case you'd need to
de-dup the prefixes).

Another potential issue is that prefixes will be assignned based on the order
they are encountered in an element's attributes collection (and this attribute
order may be different based on different UAs).

Perhaps it would be safer (and more resilient) to have the spec define an
implementation-specific algorithm that generates a unique number for a given
namespace (the hashing protocol you described), and that the number<->namespace
mapping must be consistent for this namespaceURI wherever it is encountered
(and not already associated with a prefix). That way you solve the
first-mentioned problem, and don't imply an order in the second problem. An
implementation-specific algorithm could use an incrementing number, or a
10-digit hash--the spec requirement might only describe the "ns" prefix part.

On the other hand all that might be overkill for this rather edge-case
scenario.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 27 February 2014 23:53:13 UTC