[statement_validation] rename traits to avoid ambiguity

[pchampin]

as pointed out by @GordianDziwis, the name IriValid could be read as "valid IRI", implying that the trait Iri could yield invalid IRIs...

see #6 (comment)

[pchampin]

@GordianDziwis I can not request a review from you, but as this responds to one of your comments, I would appreciate your review on this

[GordianDziwis]

I still think, that factoring out the validation code is a case of premature optimization. For example, in _iri.rs there is the comment:

r2c2/statement/src/_iri.rs

Line 3 in d9e2158

/// Wrapper around a [`Cow<str>`] guaranteeing that the underlying text satisfies [RFC3987].

The thing is, right now the wrapper does not guarantee that Iri satisfies [RFC3987]!

[pchampin]

The thing is, right now the wrapper does not guarantee that Iri satisfies [RFC3987]!

The word "guaranteeing" is meant to describe the contract of the type. It is true that the type does not provide any method to enforce the contract, but that does not make the statement wrong, IMO. But I'm open to a more explicit wording, if proposed.

[GordianDziwis]

The word "guaranteeing" is meant to describe the contract of the type. It is true that the type does not provide any method to enforce the contract, but that does not make the statement wrong, IMO. But I'm open to a more explicit wording, if proposed.

“assuming” is a better fit. The new method from the validation trait then does the "guaranteeing"

[pchampin]

The word "guaranteeing" is meant to describe the contract of the type. It is true that the type does not provide any method to enforce the contract, but that does not make the statement wrong, IMO. But I'm open to a more explicit wording, if proposed.

“assuming” is a better fit. The new method from the validation trait then does the "guaranteeing"

It really depends where you stand.
As a consumer of an Iri value, you have a guarantee that the underlying text is a valid IRI -- unless, of course, somebody messed up upstream, but separation of concern makes it not your problem.
As a producer, you need to be careful how you construct the IRI: if you use new_unchecked, it is your responsibility to enforce the contract (and the documentation of this constructor does use the verb "assume" as you suggest). If you use new, the contract will be automatically enforced.

That being said, I agree that the current documentation of Iri and LangTag can be confusing, as the word "guarantee" only make sense from the point of view of the consumer, not the producer. I'll proposed an improved text in a separate PR (because I don't want to mix work items in the same PR).