- 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