On 15-03-13 12:34 PM, Raffaele Viglianti wrote:
On Fri, Mar 13, 2015 at 3:13 PM, Lou Burnard
wrote: On 13/03/15 18:01, Raffaele Viglianti wrote:
2: defaultVal indicates that when the attribute is not present, the
definition of the element is affected *as if* the optional attribute were provided with the given value.
What on earth does this mean? The definition of the *element* is what it says in its <desc> : there might be cases where we agree that <foo type="bar"> means something slightly different from <foo type="dingo"> but the definition *of the element* remains unchanged.
The definition of the element is not changed, but at least further qualified by the attribute? Perhaps then 1 and 2 are not that different, except that the second one would not force a parser to add the default attributes. This is still valuable, I think.
Let's take att.entryLike (the first one with a defaultValue that I chanced upon) - we still want to specify that any member element should be of type "main" unless otherwise specified, without having to force every said element to occur with a @type="main".
But it's meaningless for something to be of type "main" if there are no other types, surely? I see a value in defaultVal for project-level ODD files, where you decide to save your team a lot of typing by assuming that if @type is missing, then it's "main" (but other @type values appear in the project). But I don't think it makes sense to have them in tei_all. Cheers, Martin
If what I just described is not the behaviour we want for default values, then we should certainly drop them.
Raff
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived