- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 23 Jan 2006 01:50:31 +0000 (UTC)
- To: Doug Schepers <doug.schepers@vectoreal.com>
- Cc: www-svg@w3.org
On Thu, 12 Jan 2006, Doug Schepers wrote: > > Ian Hickson wrote: > | > | My e-mail was in reply to Robin's e-mail and was covering the lexical > | space, not the value space. If you grant that there will not > | be parser re-use, then I don't understand what you are asking. > > I'm not speaking for the WG on that point, but I do personally advocate > different parsers. Then we are in agreement. > Is it somehow stated or implied in the SVG Spec that there is no need > for a different parser? The current SVG Tiny 1.2 spec has a number of issues in this area, which have been raised as last call comments. For example, I raised the issue that in section 6.6 the current text claims to re-use CSS2's syntax, which, as we have already established, is clearly not the intention. > I'm trying to make sure that I understand the issue fully. I am not sure exactly which issue you are referring to. There have been numerous issues raised, of varying levels from minor typos, editorial problems, contradictions, and fundamental differences in expected design. > Would you be satisfied with a resolution that different parsers are > required for presentation attributes and presentation properties? Such a requirement is meaningless; specs should not make requirements at this level. Whether a vendor wishes to use one complex parser or two simple parsers is an implementation detail that does not affect interoperability. In any case, I am not sure what you mean by "would I be satisfied". Satisfied in terms of what? There are numerous issues I and others have raised that would not be resolved by such a statement. I'm not sure exactly what it is you are trying to solve here. > Finally, what issues do implementors see with this approach? If there > are no significant issues, and if (subjunctive if, not stative if) it is > the general consensus that we need different parsers, what is all the > fuss about? I don't know. > | The value space is not an issue as far as I know. > > Thanks for the clarification. To further clarify, though, isn't it fair > to say that except for scientific notation and unitless lengths (both of > which could be solved by simple casting to a CSS-supported lexical > value), SVG's value space is compatible with CSS's, even if the converse > is not true? There is no "casting" required, even for scientific notation and "unitless lenghts". Those are merely syntactic details -- lexical details, that do not affect the value space. > To restate: if a UA had a heavy investment in its existing CSS parser, > or had limited resources, I think the same parser could be used with the > minor addition of a casting mechanism to resolve those 2 issues. Would > you agree with that, Ian? I would not, nor do I think such a consideration is relevant to this discussion. > | (There might be some ambiguity with rgba(), but that is > | easily solvable by simply defining it one way or another.) > > Could you elaborate on this? I'd like to know what the problem is, and > what your proposed solution would be (and whether it should fall upon > the SVG WG or CSS WG to resolve it). I'd rather keep that discussion separate, as this thread has already merged multiple issues into one to the point that we clearly do not understand what we are talking about anymore. Adding yet more distinct issues to this thread would not help. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 23 January 2006 01:50:38 UTC