I agree with Romain. The internal representation is expanded from the json representation and specified in the spec for the benefit of interoperability, but it is the json representation which is validated via a json schema.

My expectation would be that the algorithm itself defines precisely (I think it does, to be double-checked) what term is created (or not) when a value causes a validation error.

Not for all values. If something is invalid, or not specified, and there is a default, that default may get swapped in.

But if a date, for example, doesn't exactly match the ISO spec format, you can't replace it with anything. Is it worth completely tossing the property just for that reason?

But given the nature of our manifest, most data is harmless, so I personally don't care if we drop the statement. It might look stupid presented to a user, but their browser won't burst into flames.

But if a date, for example, doesn't exactly match the ISO spec format, you can't replace it with anything. Is it worth completely tossing the property just for that reason?

Yes, IMO.
In that case, the spec could say that the UA must either convert the data to an ISO date using UA-defined logic (in order to allow for clever UAs with good natural language processing), or return undefined.

Yes, IMO.

Wow, you're harsh... ;)

But I suppose in a sense that's fine, too. If we're going to be reasonably strict about metadata in the core being for processing/user configurability, then we probably need to be less lenient about invalid data.

I don't really have a strong opinion one way or the other, though, to be honest.

I updated #103 last night to ignore/remove properties with invalid values.

@rdeltour, with the merge of #103, I have closed this issue. If you think there is still something to discuss, reopen it!