[OCF]thinking more about metadata, especially parameters...

[Ragnar Kjørstad]

> I'll start by saying that I don't think that it´s
> possible to achieve 3 in its completeness. Several
> situations that would need some kind of function call
> have showed up (I think it would be nice to have a
> field in the xml that sets a library that contains
> special functions to a certain resource - for
> instance, validation functions). I have another one:
> would it be possible to store the configuration
> information in a database? If so, one can think of
> storing in a table values that should be checked
> against the input for validation. (I know that Alan
> has said something about an enum type, but I don´t
> remember as it ended..).

Are you saying the metadata should include data that
could be used to link to an apropriate library and
find functions for validation? It sounds messy, and 
the only benefit from a "validate-field" action in 
the RA is that you get a library interface rather than
an executable, so it's faster. (In case you didn't 
read that particular suggestion; the idea is to do
something like 
"/ocf/init.d/filesystem validate-field device /data"
And the script will output errormessages and give
a non-zero return code if the data was invalid)


Could you explain the database option in more detail?
I'm not sure what you're suggesting.


> For solving 2, I thought of using Grammars (more
> specificaly, Context-Free Grammars or BNF). Each
> resource could have a grammar that defines its syntax.
> It´s independent of any programming language, and
> helper functions could be built in several languages.
> Good parsers could be efficiently built based on these
> grammars.

I suggested using regexp to define the legal values, but BNF
may very well be more suitable. The only downside I see is
that it's usually more work to code, right?

> For 1, I don´t see many options. With grammars we
> could get more precision to know where the error
> occured, but I don´t know if it´s enough. Maybe, the
> easiest solution (and yet practical) would be to
> provide a human readable description of how the field
> should look like (like a regexp "translation") and
> print this information in the case of an error,
> instead of trying to locate where exactly in the input
> the error occured.

Instead of a single regexp-rule, we could use multiple regexps,
each one with an error-message attached to it. IOW; a set
of rules, and a description of what's wrong if that particular
rule doesn't match. As for BNF I think a different approach
would be needed. I suppose some information can be retrieved
from the parsing-process itself, but errormessages would easily
become cryptic this way. 

I'm not so sure that we actually _need_ more information than
"This is not a valid value for IP-adress" along with the
description of the field which can include examples or 
whatever.

If we do the validation within the RAs, like Alan proposed
("validate-field" action) it's really an implementation issue
and not a problem for the API itself.



-- 
Ragnar Kjørstad
Big Stoarage