Re: TWO Change proposals for ISSUE-41 : Distributed Extensibility

Ennals, Robert, Tue, 16 Mar 2010 03:28:11 +0000:

> Proposal X: compatible with XML namespaces:
  ....
> *  X allows an extension spec to define new element types while Y doesn't 
[...]
> 
> The ideas in common are:
> 
> * A prefix has a fixed meaning.
> * A prefix should be registered in a wiki (or something else 
>     similar) to avoid clashes.
> * An experimental prefix starting with "x-" can be used 
>     without registering.
> * A document will parse the same in XML and HTML.

I suggest these changes to Proposal X:

* Align it with Y, by saying that it can only define attributes.
* Require namespace prefixes to begin with the character "_". 
	This in order to, as much as possible, avoid clashes with 
    currently found namespace prefix talismans in text/html. An 
    element in text/HTML cannot begin with the character "_",
    which would be a positive side effect. Other namespace
    declarations, without the "_" could still be valid - at least
    as talismans.
* Align it more with how XML namespaces now work/are used by 
  registering URIs instead of registering prefixes in the Wiki/
  registry.
* Registry could *also* contain *recommended* prefixes per URI.
    Kind of like Public identifier vs URI in DOCTYPEs: The HTML4
    Strict DOCTYPE is valid both with and without the URI. But if
    you use a non-official URI, then it doesn't mean "HTML4Strict" 
    anymore. Thus it would be valid with another prefix/URI
    combination than the recommended one. The only difference 
    that authors should feel when using a non-recommended prefix
    should be that it perhaps would not work *as well* out of the 
    box. One would e.g. need to take steps to avoid the effect of
    pre-bound prefixes.
* Registered, recommended prefixes *could* be used without any
    xmlns:prefix="URI" present in the document.
* Allow unregistered URIs and prefixes.
    But then *URI* would then be a must, to be valid.
* Require that attribute names are identical with the prefix name.
    This would naturally limit the amount of attribute *names*
    and instead put the focus on attribute *values*. It would be a
    way to naturally make authors avoid creating the same prefixes.

Example of the above rules:

	<html xmlns:_foo="http://foo.example.org">
		<style> [*:_foo=bar]{color:red}</style>
		<div _foo:_foo=bar >xyz</div>

The point with the CSS in the example above, is to demonstrate that, 
once User Agents start to support this subset of XML namespaces in 
text/html, then authors will be able to use selectors without declaring 
any namespace in CSS. I.e. they can do this:

[*|_foo]{color:red}

Instead of doing this:

@namespace _foo "http://foo.example.org";
[_foo|_foo]{color:red}

Although it would also be possible to declare CSS namespaces for those 
that want to.

CSS/User Agents could also be updated to have default support for 
(some) registered prefixes, so that authors would not need to declare 
them in their style sheets.

For JavaScript/DOM, if the script knows that the attribute is "_foo", 
then it would also know that the prefix is identical.
-- 
leif halvard silli

Received on Tuesday, 16 March 2010 13:39:25 UTC