On Tue, 13 May 2008 10:05:59 +0200
Philippe Bergheaud <[EMAIL PROTECTED]> wrote:

> Inside a dim library namespace, an item version is
>         Item:Version

We should distinguish between output and input. When printing a full
version, we still have Item-Version (and only this pattern, never
Item:Version). The short form is Version.

At input, we can have Item-Version or Item:Version or Version
or :Version. To me, this list is not exhaustive. For ex. we could also
accept any substring which returns a unique match.

In other words, we want to be precise consistent and unique on output,
and tolerant on inputs.

If we do not specigy input or output, I assume that we are talking of
output, which is more restrictive. In that case, Item:Version is not
correct. Item-Version is.

> Item is
>         [A-Za-z0-9_][A-Za_z0-9_.]*

Ok.

> Version is one of
>         [A-Fa-f0-9]{40} # sha1 checksum
Again, checksum output is only [a-f0-9]{40}. Input could tolerate your
extended form.

>         +[1-9][0-9]*    # clone number
Ok. Only clones have this naming. This is mutually exclusive with the
other readonly versions which have a version name defined in the
following.
>         Name[(-Name)+[(--Name)+]]
> Name is
>         [A-Za-z0-9_][A-Za_z0-9_.]*
Ok. In addition, Names matching checksums are forbidden, i.e. you can
not alias a checksum with another checksum.

> The syntax Item:Version can be relaxed into one of
>         Item-Version            # used for tarballs
>         Item
>         Version
>
To me, this is the other way around:
the syntax Item-Version can be relaxed into any one of
        Item:Version
        Item
        Item:
        :Version
        Version
This is not exhaustive. I'm not sure if it is necessary to specify
all possible combinations at this stage.

> A file or directory Pathname is one of
>         \.[^\n]*                        # starts with .
>         [^.\n]*[^-+A-Za-z0-9_.\n][^\n]*
> Pathname syntax can be relaxed into whatever
>         [\n]+
> 
I don't get it. Where are the directory separators (/)?

> Ambiguity will be lifted by a heuristic not yet documented.
> 
You mean ambiguity at input. Output should never be ambiguous.

> Philippe

Marc
--
Archive: http://www.mail-archive.com/dim@ml.free.fr/
To unsubscribe: mailto:[EMAIL PROTECTED]

Reply via email to