On 10/12/12 23:39, Sebastian Rahtz wrote:
> 1. examples for <q> and <quote> don't have quote marks in the source
> but <said> has one example with and one without. The one _with_ quotes
> has them outside the tag, contradicting the guidelines own request that
> "the quotation marks should be included within the element, rather than outside it,"
I think the inconsistency makes this a corrigible error. I also think
it's probably better to include quote marks inside the element, since
one reason for retaining them might be to examine punctuation practice
within quoted matter, but other people might have other views.
> 2. <quotation>, which "specifies editorial practice adopted with respect to quotation marks in the original",
> is an optional element, with an optional @marks attribute, where the value "all" (all quotation marks have been retained)
> is tagged as default.
> the first is just confusing and contradictory in the usual manner of the Guidelines. But the second
> seems to be simply impossible to understand. IF <quotation> is present, with no @marks,
> the value 'marks=all' is assumed - but we have no way to express that in RELAX NG schemas,
What does a schema have to do with it? The purpose of the <quotation>
element is not to help a validater -- by the time you get to processing
this element it's too late! Its purpose is primarily to document how the
(valid) markup should be interpreted, i.e. whether or not the absence of
quote marks in the encoding implies that they were also missing from the
source. What you do with that information is up to your processor: both
situations are valid.
> so how can I implement it? And what if <quotation> is NOT present? what is the default then?
If the <quotation> element is missing then the encoder has chosen, for
whatever reason, not to tell you about their practice in this respect.
So you're at liberty to decide for yourself what to do about it.
> I suspect that default on <quotation>/@marks should be removed, as it
> is implying interpretations that it cannot fulfil.
I don't follow your logic here, though I agree that in general default
values on optional elements are a bit of a pain.