On Apr 11, 2007, at 6:04 AM, Sam Ruby wrote:
Anne van Kesteren wrote:
I think I'd rather have something simple such as prefix_name for
extensions made by ECMAScript libraries, etc. (As opposed to an in
scope xmlns:prefix="http://..."; with prefix:name extensions which
work differently in XML.) That would also work better for element
extensions. Not any of this should be allowed, but there seems to
be some desire to have an ability to introduce "conforming"
extension elements / attributes which are implemented using a
script library.
This leads into lots of tangents.
1) re: "prefix_name" - how are prefixes registered? Henri is free
to correct me if I am wrong, but I gathered that the requirement
was for a bit of decentralized extensibility, i.e., the notion that
anybody for any reason could defined an extension for holding
private data; and furthermore could do so without undo fear of
collision.
If these are meant for script-private data, I think the same ad-hoc
collision avoidance that works for the script libraries themselves
might work.
2) I assert that the existing DOM standard already defines a
mechanism for decentralized extensibility. Most relevant to the
discussion at hand is the getAttributeNS method. It may not be
defined as clearly as it could be, but there does seem to be some
clues which suggest what the original intent was, and the
beginnings of an agreement that if more browsers were to conform to
that intent, that would be a GOOD THING(TM).
getAttributeNS is definitely not a good choice for HTML, because no
current HTML implementation will recognize namespace declarations in
HTML and allow use of the relevant namespace URI with getAttributeNS.
Passing a QName to getAttribute might be workable but would require a
change to at least some XHTML implementations so that scripts can
work the same in HTML and XHTML. However, this ends up giving
semantic weight to the namespace prefix, not the namespace URI, and
so has no better collision avoidance in practice than an ad-hoc
prefixing mechanism.
I will also add that the details XML namespaces can be quite
difficult to understand, even for experts, so I would be hesitant to
spread their use to HTML.
Regards,
Maciej
