On 15-03-13 11:24 AM, Raffaele Viglianti wrote:
On Fri, Mar 13, 2015 at 2:13 PM, Martin Holmes
wrote: In the case of msPart, consider people like Gaby, who have been happily using msPart for cases of "virtual manuscripts" (according to his post to TEI-L). If you now assign a value of "part" to @type on msPart by default, suddenly all his files will contain an implicit assertion which is contrary to the truth.
But then both Gabby's files and other msParts without @type could mean either... which to me seems more dangerous if not rectified.
It might well be covered in his encodingDesc. If it is, then a new defaultVal for @type will make a liar of his encodingDesc.
Also, even if for the best reasons imaginable, Gabby has been using msPart wrongly according to the current definition, right?
Possibly, or maybe he's just been taking advantage of some possible confusion in the general understanding of what msPart is for. Cheers, Martin
Raff
Cheers, Martin
On 15-03-13 11:01 AM, Raffaele Viglianti wrote:
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
wrote: 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
-- 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