See also https://meta.wikimedia.org/wiki/Talk:Abstract_Wikipedia/Errors_messages_on_ZObjects

The Function Model syntax requires a Z1K1/type with a value that evaluates to a Z4/Type. Including this within the "well formed" definition seems to be at odds with the proposition that "Changes to other ZObjects in the wiki cannot impact the well-formedness of a given ZObject." Where the referenced Z4/Type requires evaluation (e.g. for a Z8/Function or a Z10/List), its value depends on the function it references and upon that function's dependencies etc. I suggest that an object could be called "well formed" so long as its Z1K1 is "well formed", meaning that it could be dependent on a function that cannot, in fact, be evaluated (including one that has never existed but excluding any that cannot exist).

Thinking out loud:

I've been a bit stuck on whether the validation requirement would impede programming aware newcomers. I think if there is a default validator, whose only requirement is the prior three conditions (well formed, conforming, linked) are met then it doesn't impede them. I suspect that might then lead to more validation type behavior being implemented directly in the function implementations (as noted for people writing code that's ultra defensive), if I'm understanding this correctly (and I may not be understanding it correctly). I forget, were we thinking to have a default validator? I guess I should verify: when we ask "Should it be valid?" In the Description for this task, is that mostly looking for satisfiability against all four conditions or is there some other unstated fifth condition?

Of course the "correct" thing to do would be to require a validator as a precondition as suggested.

So I wonder if part of the answer is to have a system default validator that's basically a no-op / returns an empty list (and that an be baked into the JSON schema for all functions as opposed to being magical depending on what to encourage?), and which can be replaced with a custom validator, maybe with some strong UI hint.

Of course the other way around might be possible and it might encourage use of the system in a way that's less prone to breakage later and might allow for some types of function discovery plus maybe some performance gains in some contexts.

I don't know the answer, but I think that's the main stuff I've been struggling with. It may be that some recent code changes are addressing this, though, too.

Otherwise: the work lists idea is good. And the requirement that a function be "valid" before it gets executed seems reasonable as a design principle. It seems like the main question is about the validator function and whether to require it to be user supplied and, if not, whether to have a default validator (which basically returns an empty list if the prior conditions of well formed, conforming, and linked are met). I can see how it might influence certain behaviors in the system.

Let's consider lazy evaluation.

I suppose I should be able to create an object that cannot be fully validated because its Z4K2/keys cannot be fully expanded/evaluated? So how deeply should we evaluate an instance of a Z4/Type, for validation? My instinct is, "not very deeply", but my instincts are certifiably unreliable.

To take a simple example, if there is a validation requiring a string to have length 2, we can say an object is valid if it happens to reference a function whose Z8K1/return type is a string with length 2, and we can say it is invalid if the Z8K1/return type is not a string or is a string with length <2 or >2. But if the return type is just Z6/String, we don't know whether it's valid or not, unless we evaluate it. In such a case, I think we should return an error (so it's not valid). Then the contributor can

1. change the referenced function's return type (having saved the "invalid" object) or
2. wrap the referenced function in a function with an appropriate return type.

In T269182#6688805, @GrounderUK wrote:

The Function Model syntax requires a Z1K1/type with a value that evaluates to a Z4/Type. Including this within the "well formed" definition seems to be at odds with the proposition that "Changes to other ZObjects in the wiki cannot impact the well-formedness of a given ZObject." Where the referenced Z4/Type requires evaluation (e.g. for a Z8/Function or a Z10/List), its value depends on the function it references and upon that function's dependencies etc. I suggest that an object could be called "well formed" so long as its Z1K1 is "well formed", meaning that it could be dependent on a function that cannot, in fact, be evaluated (including one that has never existed but excluding any that cannot exist).

You are right. Well-formedness should not require a valid Z4 on the Z1K1 for exactly the reasons you describe. I fixed that as suggested. https://meta.wikimedia.org/w/index.php?title=Abstract_Wikipedia/Function_model&diff=next&oldid=21100248&diffmode=source

In T269182#6701811, @dr0ptp4kt wrote:

Thinking out loud:

I've been a bit stuck on whether the validation requirement would impede programming aware newcomers. I think if there is a default validator, whose only requirement is the prior three conditions (well formed, conforming, linked) are met then it doesn't impede them. I suspect that might then lead to more validation type behavior being implemented directly in the function implementations (as noted for people writing code that's ultra defensive), if I'm understanding this correctly (and I may not be understanding it correctly). I forget, were we thinking to have a default validator? I guess I should verify: when we ask "Should it be valid?" In the Description for this task, is that mostly looking for satisfiability against all four conditions or is there some other unstated fifth condition?

Of course the "correct" thing to do would be to require a validator as a precondition as suggested.

So I wonder if part of the answer is to have a system default validator that's basically a no-op / returns an empty list (and that an be baked into the JSON schema for all functions as opposed to being magical depending on what to encourage?), and which can be replaced with a custom validator, maybe with some strong UI hint.

Of course the other way around might be possible and it might encourage use of the system in a way that's less prone to breakage later and might allow for some types of function discovery plus maybe some performance gains in some contexts.

I don't know the answer, but I think that's the main stuff I've been struggling with. It may be that some recent code changes are addressing this, though, too.

Otherwise: the work lists idea is good. And the requirement that a function be "valid" before it gets executed seems reasonable as a design principle. It seems like the main question is about the validator function and whether to require it to be user supplied and, if not, whether to have a default validator (which basically returns an empty list if the prior conditions of well formed, conforming, and linked are met). I can see how it might influence certain behaviors in the system.

Yes to all. Those are great thoughts.

So, agreed, we should require validation. But in order to not impede newcomers, it should be possible to save an object even if certain levels are not validated.

I would suggest that:

• in the normal case, when the contributor tries to save, we run a full validation.
• we will revisit that decision once validation starts to take consistently longer than 2 seconds for any type.
• if the validation passes, we store the object.
• if the validation does not pass, we return the error message.
• now the contributor can redo the change.
• if the object is at least conforming they can also check a checkbox that allows them to force storage of the object.

This should allow for some errors to store and to allow other contributors to work for it. Also, as stated above, we would have special pages that list all unlinked, uncheckable, and invalid objects.

In T269182#6704036, @GrounderUK wrote:

Let's consider lazy evaluation.

I suppose I should be able to create an object that cannot be fully validated because its Z4K2/keys cannot be fully expanded/evaluated? So how deeply should we evaluate an instance of a Z4/Type, for validation? My instinct is, "not very deeply", but my instincts are certifiably unreliable.

To take a simple example, if there is a validation requiring a string to have length 2, we can say an object is valid if it happens to reference a function whose Z8K1/return type is a string with length 2, and we can say it is invalid if the Z8K1/return type is not a string or is a string with length <2 or >2. But if the return type is just Z6/String, we don't know whether it's valid or not, unless we evaluate it. In such a case, I think we should return an error (so it's not valid). Then the contributor can

1. change the referenced function's return type (having saved the "invalid" object) or
2. wrap the referenced function in a function with an appropriate return type.

In this case we would create a new Type, "String with length two". Now we can plug-in any Function whose return type is "String with length two" into any slot that requires a "String with length two". We don't need to evaluate the Function: because its return type is "String with length two" we know it will return "String with length two". We have a nominal type checking here.

We would not allow for a Function that declares it returns Z6/String in this place, and hope that it has length 2. We would insist on the Function to return "String with length two".

(Note that in a real setting we would be probably having a Function called "String of specific length" that takes a positive integer as an input and returns a Type. We would still require a nominal equality - that is why we have the identity as a key on Types, so that we can use this identity to compare two Types for equality)

I hope that makes sense.

I think that makes sense. For my first option, I should have stated that the change to the referenced function’s return type would be from the more general to the more specific (e.g. from Z6/String to Z?/2-string).

My point, though, was that I seem to have a problem with the workflow. It is the referenced function that needs to change, not the one I’m editing now. I can’t save my “correct” function, because the referenced function’s incorrect return type makes my function “invalid” (for now). So do I save it with this error (my first option)? Or do I pretend to coerce the Z6 to a 2-string (my second option)? I don’t like either option, because they both assume I’m reliable, but at least the error with the first option will clear itself if I make the correct change to the other function. So I’d rather save a “correct” object with an error than avoid the error by making the object less correct (for the time being). Under your latest proposal, I would get a single error initially and then choose to force the save anyway, so we’re good.

The following tasks will implement the changes suggested here:

• block publishing / storing if validation fails (this already happens)
• display error messages from validation (this happens now)
• T273124 - call evaluator for validation
• T273125 - migrate hard-coded validators
• T278316 - provide validation as a service / API
• T278318 - possibility to call validation on an unstored object
• T278319- possibility to call validation on a stored object
• T278320 - override the blocking on storing an object even if it doesn't validate
• T278321 - special page with all invalid pages
• T278325 - store invalidity