It seems to me that there are two conflicting interpretations of defaultVal
at play:
1: defaultVal indicates that an optional attribute will be provided by a
parser with the given default value
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.
The first is intrusive and seems to belong to a past SGML/XML world.
The second is helpful, but requires revisiting its current definition in
ODD (ie it must be for documentation only) and revisiting its current use
in the guidelines.
Rather than getting rid of defaultVal altogether, I would prefer to fully
adopt the second interpretation. As a case in point, if we decide to
introduce a @type on msPart, it may be useful to set its default value to
"part" (or whatever will be the opposite of "fragment") so that we don't
break backward compatibility of applications that parse/output msPart
according to the old definition.
Raff
On Thu, Mar 12, 2015 at 8:37 AM, Hugh Cayless
As you’ll probably have seen from the slew of sourceforge emails, I’ve made an almost totally random assignment of bugs to the folks with the fewest bugs/FRs on their plates. I didn’t assign the one unassigned FR ( https://sourceforge.net/p/tei/feature-requests/546/ < https://sourceforge.net/p/tei/feature-requests/546/> —which is Lou’s) because we didn’t get to discuss it. Can we do so now via the list?
Thanks all! Hugh
-- 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