Hi Raff, I must admit I'm against defaultVal in both its interpretations. I'd especially like to get rid of #1 (which I think would involve changes in ODD processing), but I don't like #2 either, because I'm not keen on the idea that there's "data" in your file that you can't actually see. I think defaultVal more often annoys and confuses (through the insertion of attributes you never even noticed you were "using") than it helps anyone. I just don't like the idea that the absence of something implies a value for it. 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. 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

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

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". 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