- From: Simon Sapin <simon.sapin@kozea.fr>
- Date: Sat, 11 Aug 2012 08:56:03 +0200
- To: www-style@w3.org
Le 11/08/2012 03:44, Kang-Hao (Kenny) Lu a écrit :
>> [...]
>> The two are contradictory about empty strings.
>
> This can be read in a non-contradictory way. The sentence in section 2.1
> talks about the semantics (or perhaps just terminology nonsense) not
> about syntax, which is what section 3.1 is talking about. I do find the
> "null namespace" and "lack of a namespace" concept confusing: I have no
> idea why we don't just call it a namespace with namespace name being the
> empty string. I suppose that has been a terminological heritage from XML.
>
> As a data point, the css3-namespace test suite has a test[1] that relies on
>
> @namespace foo "";
>
> being valid, matching 3.1.
>
> We could have matched xml-names, but that would mean
>
> @namespace foo "";
>
> is invalid while
>
> @namespace "";
>
> is. Is this what you are suggesting?
>
> [1] http://www.w3.org/Style/CSS/Test/CSS3/Namespace/current/prefix-002.xml
This is not what I was suggesting.
According to the quoted parts of xml-names, it not possible to have an
empty string for a namesace URI that means something different than "not
having a namespace".
However, my understanding of 3.1’s "the empty string [is a] valid
namespace name" was that it was a valid name with a different meaning
than "no namespace". In other words, I thought that these two selectors
would match two disjoint sets of elements:
@namespace NS "";
NS|E {}
|E {}
while 2.1 said they were the same.
But as you say, we can read the sentence in 3.1 as a mere comment on the
syntaxic validity of a rule, not of its meaning. Therefore, the issue
only becomes editorial: the last sentence of 3.1 could be re-worded to
make it clear that it only talks about the syntax of a declaration:
# All strings—including the empty string and strings representing
# invalid URIs—are syntactically valid namespace names in @namespace
# declarations. (But note that <a href="#terminology">empty strings
# have a different meaning</a>.)
(Or perhaps add a more specific anchor in 2.1.)
Cheers,
--
Simon Sapin
Received on Saturday, 11 August 2012 06:56:38 UTC