Subject: [netmod] Pattern "ok"?

From: Phil Shafer <[email-masked]>
Date: Thu, 20 Aug 2009 15:24:24 -0400

Does the regular expression given in the "pattern" statement match
the whole string, or just a portion?  That is, is there an implicit
"^" and "$"?

    pattern "(not )?ok";   // Does this match "yokel"?
    pattern "[a-f]{1,3}";  // Does this match "tobacco"?

Given that most expressions will need to match the entire string,
can we make the "^" and "$" implicit?  Or will we allow this to be
a common source of errors?

If they are implicit, one can match a portion of the string using
".*", like:

    pattern ".*ok.*";

Thanks,
 Phil

---

From: Per Hedeland <[email-masked]>
Date: Thu, 20 Aug 2009 22:39:26 +0200

> the whole string, or just a portion?  That is, is there an implicit

There is, per the definition in [XSD-TYPES] - might also be inferred
from the last example in the draft, and maybe from "...values that
_completely_ matches the pattern." But I guess it wouldn't hurt to spell
it out.

--Per Hedeland

---

From: Phil Shafer <[email-masked]>
Date: Fri, 21 Aug 2009 10:02:33 -0400

>_completely_ matches the pattern." But I guess it wouldn't hurt to spell

Sounds good.

One more question: Is the restriction of pattern to string-based
types a CLR?  Could I not use:

    type int {
        pattern "[0-9]*[24680];
    }

to restrict my value to even numbers?  Or:

    type decimal64 {
        fractional-digits 2;
        pattern ".*\.{00,25,50,75}";
    }

Not common, but I'm just not seeing the need to restrict it to
string.  We would need to say that these strings apply to the
canonical form of the value.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 21 Aug 2009 17:01:48 +0200

> types a CLR?  Could I not use:

I think it isn't, because the regex patterns work exclusively in lexical
space.

Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 21 Aug 2009 21:58:04 +0200

> canonical form of the value.

Section 7.5.3. already says this:

   Note that since all leaf values in the data tree are conceptually
   stored in their canonical form (see Section 7.6 and Section 7.7), any
   XPath comparisons are done on the canonical value.

The text is trying to say the right thing, although the wording can be
improved - it does not matter how values are "stored" - it would be
more helpful to simply spell out that the expressions are evaluated
against the canonical representation of values.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Phil Shafer <[email-masked]>
Date: Fri, 21 Aug 2009 17:04:03 -0400

>against the canonical representation of values.

It definitely needs better wording, so cover non-xpath ('pattern'
statement) comparisons.  How about:

-  XPath comparisons are done on the canonical value.
+  comparisons from 'pattern' constraints or XPath expressions 
+  are done on the canonical value.

Are you okay with removing the string-only CLR for pattern?

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 22 Aug 2009 00:19:57 +0200

> +  are done on the canonical value.

7.5.3. is about must statements - this is the way the document is
organized; pattern are handled elsewhere.

>From the way the YANG specification is written, this is a rather heavy
editing change.

If this is really a CLR, then it is anchored deeply in the specs. I am
probably not sure yet of the value of allowing pattern for numeric
types nor do I have personally much experience with using regular
expressions to restrict number spaces - but this might just be my
ignorance.

XSD allows pattern restrictions pretty much everywhere - even for the
type boolean which has the two values 'true' and 'false'. It is kind
of difficult to come up with a use case for a pattern on boolean but
if you allow it everywhere, then there certainly is no CLR. ;-)

So what is your proposal - pattern restrictions for all types?

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 21 Aug 2009 15:24:07 -0700

> Are you okay with removing the string-only CLR for pattern?

What is the string-only CLR?

Why are we talking about changing the way patterns work now?

It is not needed for any other built-in data types besides string.

>  Phil

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 21 Aug 2009 22:50:47 -0400

>So what is your proposal - pattern restrictions for all types?

Yup.  The fix is something like:

- defined in ^XSD-TYPES^.   It is used to
- restrict the built-in type "string", or types derived from "string",
- to values that completely matches the pattern.
+ defined in ^XSD-TYPES^.  These regular expressions
+ are applied to the canonical format of the value
+ and match the complete string, with an implicitly "^"
+ and "$" before and after the given pattern string.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 22 Aug 2009 09:15:06 +0200

> + and "$" before and after the given pattern string.

Not correct. Look at the ABNF and there are other places in the text
talking about restrictions that would need to be adapted.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 22 Aug 2009 01:52:36 -0700

> Yup.  The fix is something like:

So what problem does this solve in YANG?
We have ranges for numbers, so we don't need patterns there.
We have enum strings and bit names, sure don't need them there.
We have identityrefs and instance-identifiers, sure don't need
them there. Boolean? binary?  No.

So what YANG data modeling problem does this solution address?

This is just piling on complexity without reason.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 22 Aug 2009 15:20:08 +0200 (CEST)

> This is just piling on complexity without reason.

+1

The only other type it could be used is as some kind of hack for
integer types, but if we want to provide more powerful integer
restrictions we may want to look at other statements.  For example, a
customer asked if something like this is possible:

  type int32 {
    range "10..1000" {
      step 10;
    }
  }

This would probably be more useful than pattern.  (But I don't propose
that we add it!)

> > + and "$" before and after the given pattern string.

Re. implict ^ and $, I don't think it is a good idea to point out just
this.  There are many regular expression "dialects", and we define
which one we use (XSD).  That is precise and IMO enough.  This
document is not the right place to educate people on differences
between regular expression dialects.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Sat, 22 Aug 2009 12:23:54 -0400

>> This is just piling on complexity without reason.

No, it's removing the CLR that says pattern is only valid
for string-based types.

>Martin wrote:

I think we need to point out that it's matching the complete
string, so we don't see a lot of patterns like "^ok$".

Thanks,
 Phil