[tei-council] validation of examples
mholmes at uvic.ca
Sun Jan 30 13:01:37 EST 2011
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.
More information about the tei-council