[tei-council] validation of examples

[Martin Holmes]

On 11-01-30 09:46 AM, James Cummings wrote:
> On 30/01/11 17:40, Martin Holmes wrote:
>> On 11-01-30 09:24 AM, Lou Burnard wrote:
>>> I am now wondering whether the @break attribute on<lb/>
>>> should take values "true" "false" and "unspecified" rather than "yes"
>>> "no" and "maybe" as currently proposed.
>>
>> "maybe" is very different from "unspecified". I think omitting the
>> @break attribute would be the same as making it "unspecified", wouldn't it?
>
> Doesn't this return to a discussion of what the non-presence of an
> attribute means?  In transforming from one format to another I can
> picture a scenario where I want to indicate that it wasn't the case that
> I didn't pass an attribute along, but that indeed this was unspecified
> (or unable to be specified perhaps) in the original format.
>
> With regard to @break, I think true/false/unspecified better than
> yes/no/maybe just because it sounds more formal. (Which I'm not sure is
> a good reason.)

Point taken, but I still think "maybe" is different from "unspecified". 
I think the former would be used when an encoder is not sure about 
whether it's breaking or not; the latter might be used when an encoder 
is not qualified or authorized to make a decision, and is therefore 
leaving it to be checked later by someone else.

But your use-case above suggests that "unspecified" means "unspecified 
in some ancestor document of the current document". That seems to be in 
a slightly different domain from "yes" and "no" or "true" and "false", 
which are claims about [an interpretation of] the source document, not a 
prior encoding of it.

Cheers,
Martin