- From: Ivan Herman <ivan@w3.org>
- Date: Fri, 19 Jun 2015 07:25:59 +0200
- To: Gregg Kellogg <gregg@greggkellogg.net>
- Cc: W3C CSV on the Web Working Group <public-csv-wg@w3.org>
- Message-Id: <B60DD5E4-1478-49AF-AE35-4766F7910725@w3.org>
> On 18 Jun 2015, at 22:43 , Gregg Kellogg <gregg@greggkellogg.net> wrote: > > I’m just adding the last tests for Foreign Keys, and am going over possible errors. My interpretation is the following: > > * All processors MUST halt if a if an error is raised when processing a Metadata document, or the Metadata document is invalid. (Note, a Metadata document may have recoverable errors, which generate warnings, but is still valid for the purposes of allowing a converter to continue using it). > > * All processors MUST halt if the metadata is incompatible with a starting CSV, or now CSV if found as referenced from metadata. > > * Warnings are raised for cell values not matching their datatype, and the error is noted in the Cell model. > > * Validators MUST raise an error on Primary or Foreign Key violations or for cell errors (which are otherwise warnings). > > This leaves the case where warnings are generated when processing a Metadata document (e.g., the value of `titles` isn’t a string, and is ignored). Tests currently treat this as a WarningValidationTest which do not expect an error to be raised, but warnings to be generated. However, strictly speaking, this makes the Metadata invalid (even though useable for generating JSON/RDF), and so perhaps should consider changing this to a NegativeValidationTests, where an error should be raised. > > The simplest way for a processor to handle this is for a collect both warnings and errors, then if validating, raise an error if either warnings or errors is not empty. But, this should be clarified here, and in the spec. That sounds reasonable… Ivan > > Gregg Kellogg > gregg@greggkellogg.net > > ---- Ivan Herman, W3C Digital Publishing Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 ORCID ID: http://orcid.org/0000-0003-0782-2704
Received on Friday, 19 June 2015 05:26:12 UTC