Re: summary of rdf-turtle#37

tl;dr:

  * Define based on compliance/non-compilance
  * Non-compliant would be "signal an error".
  * Don't put in required behaviour for non-compliant situations - it is
    usage dependent


On 07/07/2025 14:12, Pierre-Antoine Champin wrote:
...
> (NB the first two were also pointed out in rdf-n-triples#33 
> <https://github.com/w3c/rdf-n-triples/issues/33>).
>
> This leaves the question open of how parsers should behave when they 
> encounter such "grammatically valid" documents that result to invalid 
> RDF terms...
>
> 1. stop parsing a raise an error
> 2. refrain from emitting invalid triples, raise a warning, but 
> continue parsing
> 3. emit triples containing the invalid terms (with a warning)
>
What is important is compliance/non-compilance.

A. Complies with the spec
B. Structural bad syntax (not compliant with the grammar, parse error).
C. Not compliant RDF but at the most basic level, syntactically correct 
(or at least "tolerable")

Putting one behaviour in the spec is conflating (B) and (C).

I think the specs should define compliance/non-compliance and leave the 
handing of non-compliance out.
  e.g. spec text says "signal an error" and does define the handling of 
the signal.

Non-compliant input means RDF Semantics does not apply.

Tests can cover (B) - structural bad syntax. The community general 
agrees what's a hard error but maybe some parser attempt to recover.

What to do about (C) is a usage sensitive. There are multiple sensible 
choices: stop; no triple but continue; no triple, continue but with no 
further output; no output from the start (transaction abort); indicate 
non-compliance and continue.

In parallel parsing, it is not always stop the process at a specific point.

Normally W3C tests are to show implementability with 2 passing 
implementations of each feature. The RDF community also uses them as an 
aid to implementation interoperability in deployed usage.

  The strict W3C purpose can be done with a special parser mode but 
general interoperation is better served if parsers pass running without 
special compliance mode.

So spec text says "signal an error" is appropriate.

> is this not analogous to the situation with "support ill-typed literals with recognized datatype IRIs"?

I think this style is useful.
Data is compliant or not - semantics does not apply.

> I would like to express my strong opposition to Option 1
Agreed - one fixed mandated behaviour is not desirable. We already have 
literals being invalid by datatype.
And it is not how RDF 1.1 system work so it is arguably a breaking change.

On option 2: only having omitting triple seems dangerous. This may be 
desirable, it may not - in loading a large datafile (many hours), small 
details can get lost. Invalid literals are still possible so it isn't a 
guarantee of good data anyway.

     Andy