From: Mark Davis (mark.davis@icu-project.org)
Date: Tue Oct 02 2007 - 11:24:01 CST
On 10/2/07, Philippe Verdy <verdy_p@wanadoo.fr> wrote:
>
> Mark Davis Wrote:
> > Also, there were some interesting suggestions for syntax additions
> > that may be worth mentioning in informative text.
> > 1. not equals
> > As well as
> > * \P{propname=value} and [:^propname=value:]
> > to have:
> > * \{propname!=value}, \p{propname≠value}
> > * [:propname!=value:], [:propname≠value:]
>
> I'm not sure that \{propname!=value} should be defined, or recommended or
\{ was a typo, should have been \p{
[snip]
>
>
> Also you propose mixing \p and \P for similar use. The only good
> suggestion
> is the way to represent the "different" relation using an alternate
> operator
> replacing the equal sign, instead of using a leading negation (using a
> capital \P instead of \p, or a leading ^ operator in a class notation)
> before the encoded equality.
I don't understand I don't propose mixing them: that is standard notation,
promulgated by Perl.
For the rest, the "[: ... :]" bracketing is easily perceived everywhere as
[snip]
Again, standard notation.
> 2. multiple values(...)
> > * \p{gc=L|M|Nd} instead of [\p{gc=L}\p{gc=M}\p{gc=Nd}]
>
> Good suggestion but it is quite related to your suggestion 3:
>
> > 3. regex values
> > * propname=/regexForValue/
> > eg
> > * \p{name=/MARK/} or equivalently \N{/MARK/}
>
> So multiple values would also be encoded using your suggestion 3 as:
> * \p{gc=/L|M|Nd/}
yes. However, there is a difference in that multiple values can often be
more easily computed.
What do you mean in \p{name=/MARK/} : does this indicate that is will match
> any character whose property value "equals" the matched regexp, or
> "contains" the regexp. I would not suggest the "contains" meaning, this is
> not needed because it should be:
> * \p{name=/.*MARK.*/}
As I wrote, that's an open issue.
But then, why are the slashes needed? If you look at suggestion 2, the
> leading and trailing slash is not used, but the multiple values are also
> encoded as a regexp. So your suggestion 3 (regexp values) could as well be
> supported using the notation in suggestion 2:
> * \p{name=MARK} or equivalently \N{MARK}
No. You can't then distinguish an exact match to "MARK".
If you need to encode the "constains" relation rather than the "equals"
> relation, I think this relation should be encoded explicitly:
> * \p{name=.*MARK.*} or equivalently \N{.*MARK.*}
> At least like this, this does not change the reading of the "=" operator
> as
> "equals" in the notation, which can then be replaced where needed by a
> "different" operator or negated assertion containing the "=" operator
> (related to "does not contain" if there's a regexp in the value starting
> and
> finishing by ".*")
Trying to parse your language, what I read you as saying is that a
different equivalence operator could be used instead of the slashes, like
propname~value
instead of
propname=/value/
-- Mark
This archive was generated by hypermail 2.1.5 : Tue Oct 02 2007 - 11:26:45 CST