On 05/09/2017 19:00, Juergen Schoenwaelder wrote:
On Tue, Sep 05, 2017 at 06:17:09PM +0100, Robert Wilton wrote:
I believe that tools intended for general use should follow the YANG spec
literally.
I don't fully agree. I think that they only need to cover the parts of the
YANG spec for the models that they are using (or might use). If nobody uses
Unicode blocks then it doesn't really matter whether a given tool supports
them or not. It is always possible to caveat and add support for the
missing bits later. E.g. if I was writing a bespoke XPATH implementation
for YANG then there is probably quite a lot of the XPATH spec that I would
also leave out as well, and just concentrate on the parts that people
actually use, or are likely to use.
If this is your understanding of standards, why do you want to define
a subset of XSD pattern based on the your observation what is used or
not used? Simply do not implement what you observe is not used. Why do
we need guidelines of constructs not to use so that they are not used?
My aims:
1) To make pattern statements in standard YANG models easier to comprehend.
2) So that implementations designed to only support standard YANG models
can have more confidence that they don't need to support all of the
Unciode properties and character blocks.
There are multiple contradictions in your posts, one of them was the
idea of translating unicode matching to ASCII - which simply does not
work.
This does work if your implementation is willing to be restricted to
only supporting ASCII. Some users of YANG seem to think that ASCII is
sufficient to configure and manage network devices. My person opinion
is that they are probably broadly right, but there are some places where
supporting a unicode string is better (e.g. the interface description
leaf). However, in these cases I think that either no pattern statement
is required, or otherwise \w,\s,\d are probably sufficient.
I understand, and agree, that an implementation that restricts pattern
statement support to only ASCII strings makes the implementation non
compliant to the YANG spec.
Or the post where you said \d is OK but then later said \d is
not OK since it translates to a large number of numeric characters.
Yes, my opinion changed when I found our that '\d' covers more than just
ASCII. As per the 6087bis text that I sent out, I think that '\d' can
be used, but must not be used if the regex is meant to only match ASCII
0 to 9. My concern is that many readers/authors/implementors of YANG
models may not understand properly understand that '\d' also covers
digits in other unicode scripts, and hence I think that it is more clear
(and hence better) to use '[0-9]' in pattern statements instead, since
the interpretation of that is entirely unambiguous.
You really need to sort out what you want, what the problem is you are
trying to solve, how you select the subset of XSD pattern etc. Write
and I-D.
Do you think that writing an I-D, that would contain the same arguments
that I've presented here, would sway your opinion at all?
My assumption is that it wouldn't and hence writing up an ID would seem
to be a waste of effort.
And at the end, people who only do POSIX regular expressions,
because they come with the standard C library on POSIX systems or
whatever the reason really is, still will either have to continue to
cheat by silently interpreting XSD pattern as POSIX pattern or they
create a proper new statement to at least properly distinguish
different pattern languages.
Sure, but I don't regard either of these as good long term solutions.
Thanks,
Rob
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
