How to make <defaultVal> deletable?

[joeytakeda]

I'm trying to do two things here: 1) Make an attribute required and 2) delete the default value for that attribute from an <elementSpec>. Is there any way to do this? I'm doing this for <egXML>:

<elementSpec ident="egXML" module="tagdocs" mode="change">
                  <attList>
                     <attDef ident="style" mode="delete"/>
                     <attDef ident="rendition" mode="delete"/>
                     <attDef ident="corresp" mode="delete"/>
                     <attDef ident="resp" mode="delete"/>
                     <attDef ident="cert" mode="delete"/>
                     <attDef ident="source" mode="delete"/>
                     <attDef ident="facs" mode="delete"/>
                     <!--Need to know validity of the EGXML-->
                     <attDef ident="valid" mode="change" usage="req" >
                        <!--Don't know what to do now-->
                     </attDef>
                  </attList>
               </elementSpec>

If I give a value of <defaultVal/> like so, it appropriately thinks that I am trying to give it an empty defaultVal, which I don't want to do (and it gets mad at me, since it makes no sense to require an attribute and not give it a value).

<defaultVal> isn't a member of att.combinable, so I can't do this:

<defaultVal mode="delete"/>

So other than copying the spec for @valid and leaving out the <defaultVal> element, is there a way to delete the <defaultVal>? If there isn't, could <defaultVal> be added to att.combinable so that one could delete it?

[martindholmes]

In such cases I just copy out the original spec and delete/change as necessary.

[martindholmes]

@joeytakeda Does this solve your problem? If so, could you close the ticket? (For the record, I think anything more complicated such as allowing @mode on <defaultVal> would lead to an inordinate amount of work that nobody will really want to do. :-))

Also, to make the attribute required, just add @usage="req" to the <attDef>.

[sydb]

And to be fair, if an attribute sepcification is required by the schema, then it does not matter a hoot what the schema thinks will be the default value is. That said, and add to it that @martindholmes is correct above (just need @usage="req", I just tried it and it did not work for me. Well experiment more later.

[martindholmes]

This works perfectly for me:

<elementSpec ident="egXML" ns="http://www.tei-c.org/ns/Examples" mode="change" module="tagdocs">
               <attList>
                  <attDef ident="valid" mode="replace" usage="req">
                     <desc versionDate="2011-01-30" xml:lang="en">indicates the intended validity of the example with respect to
                        a schema.</desc>
                     <datatype><dataRef key="teidata.enumerated"/></datatype>                     <valList type="closed">
                        <valItem ident="true">
                           <desc versionDate="2011-12-04" xml:lang="en">the example is intended to be fully valid,
                              assuming that its root element, or a provided root element, 
                              could have been used as a possible root element in the schema concerned.</desc>
                        </valItem>
                        <valItem ident="feasible">
                           <desc versionDate="2011-12-04" xml:lang="en">the example could be transformed into
                              a valid document by inserting any number of valid attributes and child
                              elements anywhere within it; or it is valid against a version of the
                              schema concerned in which the provision of character data, list, element, or attribute
                              values has been made optional.</desc>
                        </valItem>
                        <valItem ident="false">
                           <desc versionDate="2011-01-30" xml:lang="en">the example is not intended to be valid,
                              and contains deliberate errors.</desc>
                        </valItem>
                     </valList>
                  </attDef>
               </attList>
            </elementSpec>

[sydb]

And this fails to make @usage required for me:

      <elementSpec ident="egXML" module="tagdocs" mode="change">
        <attList>
          <attDef ident="style" mode="delete"/>
          <attDef ident="rendition" mode="delete"/>
          <attDef ident="corresp" mode="delete"/>
          <attDef ident="resp" mode="delete"/>
          <attDef ident="cert" mode="delete"/>
          <attDef ident="source" mode="delete"/>
          <attDef ident="facs" mode="delete"/>
          <!--Need to know validity of the EGXML-->
          <attDef ident="valid" mode="change" usage="req" />
        </attList>
      </elementSpec>

using the CLI roma that y’all want to stop supporting.

---

Error found: I did not have @ns specified on my <elementSpec>, so it was summarily (and silently) ignored.

[joeytakeda]

What @sydb is doing was exactly what I did originally, and then realized that no one was actually explicitly encoding @valid since there was a default value on it. The usage is required, as far as I can tell, but (correct me if I'm wrong) since there's a default value, the usage requirement is always already met.

I'm happy to do what @martindholmes suggests above (as I noted at the end of the OP :-)), but I just don't love it, since that means that the local definition of @valid is always tethered to a version of the release and won't get updated afterwards. (And, to be fair, in this case I'm perfectly fine with the default value, but I do think that not being able to remove a <defaultVal> seems odd.) However, I understand that in terms of cost/benefit, this is a low priority feature request, so I'm happy for this to close if council wants to close it.

[martindholmes]

@joeytakeda you're perfectly correct that this is not ideal. The problem really is twofold. First, it's not clear whether @mode is supposed to apply to other attributes defined on the element which has the @mode attribute, or only to child elements of it. I think most people would assume (as we all did originally) that it should cause attributes defined on the same element to be processed (its gloss is "specifies the effect of this declaration on its parent object"), but that's not what happens. Whether that should be the case or not is the first thing. If it should be the case, then a Stylesheets ticket needs to be raised to handle it.

[sydb]

If I understand you correctly, @joeytakeda , then no, it’s not that the usage requirement is met by the default value, but rather that the default value is rendered useless by the usage requirement.

But back to your original point, I cannot come up with a reason (off the top of my head) why <defaultVal> should not be a member of att.combinable, except that it does mean that someone has to update teh stylesheets to make it work!

[lb42]

1. @mode is meant to apply to all the child elements of the element bearing it. But @mode=change doesn't allow you to remove any of the children -- just replace them with better versions. Hence your problem
2. Since your goal is to change two properties of an attribute (at least), it would make better sense (as @martindholmes proposes above) to supply a new complete specification for that attribute and supply it with @mode=replace . This has two advantages: (a) it works (b) it makes it clearer to anyone looking at your ODD what you're trying to achieve.

[martindholmes]

We haven't specified clearly enough what we intend by @mode="change". I fear that what we've ended up intending is what has ended up being practical, not what is intuitively expected by users.

Part of me thinks this doesn't matter because THERE SHOULDN'T BE DEFAULT VALUES ANYWAY. Why don't we just get rid of them and this specific problem goes away.

[joeytakeda]

I absolutely agree with Martin’s second point: defaultVals are annoying and cause problems such as this (I was actually just thinking about all the defaultVals I’d delete if defaultVal was made a member of att.combinable).

And I understand where @lb42 is coming from, but, as I said in the OP, I know that just rewriting the specification is easier because it works, but is a lot of work for something that I think should be quite simple. To me, I see no reason why if you can elegantly add attribute values, delete them, change them, add restrictions to the data type, etc etc in a number of ways in ODD, why can’t you just get rid of the silly default value?

[sydb]

I agree with @joeytakeda (and @martindholmes, I think), that having @mode on <defaultVal> makes more sense than replacing the entire specification. (That said, @joeytakeda, replacing the specification works right now, so for the moment that’s obviously what you should do. :-)

As I’ve said elsewhere (and is not really the topic of this ticket), I would prefer not to get rid of <defaultVal>, but rather to change the semantics from a command to a validator “if this attr is not specified, insert it with this value” to a hint for a processor “if the user did not specify this value, this is probably what she meant”.

And, no matter how you look at it, @joeytakeda , it makes no sense to have both usage-"req" and <defaultVal>. In fact, the tei_customization schema considers this an error:

      <rule context="tei:attDef[@usage eq 'req']">
        <report test="tei:defaultVal">It does not make sense to make "<value-of select="normalize-space(tei:defaultVal)"/>" the default value of @<value-of select="@ident"/>, because that attribute is required.</report>
      </rule>

[joeytakeda]

And, no matter how you look at it, @joeytakeda , it makes no sense to have both usage-"req" and . In fact, the tei_customization schema considers this an error

Yes, that make completes sense. So, I suppose to make the formal request:

1. Add defaultVal to att.combinable
2. Add handling in the stylesheets for 1)

If 1 is approved, I can make a ticket for 2.

[martindholmes]

I'm not saying <defaultVal> should not exist; I'm saying we should never use it in the Guidelines specs themselves, since the net effect is that people "use" attributes they've never even heard of. I would prefer removing all our <defaultVal>s to facing the Stylesheets issue for something we don't want anyway.

[sydb]

(Ummm... we should probably move this discussion to the appropriate ticket, no?)

I'm not saying should not exist; I'm saying we should never use it in the Guidelines specs themselves

And (at least at the moment) I respectfully disagree. I think <defaultVal> should not exist in its current form — it should mean something else.

But I’m not sure I understand what you mean by "facing the Stylesheets issue for something we don’t want anyway”. We need to allow users to delete <defaultVal> even if it does not appear in our Guidelines or we change the semantics slightly.

[martindholmes]

If we don't use it in the Specs, then nobody should need to delete it. If they don't want it, they don't add it to their ODDs. The number of people who will add it to an ODD, then override that and delete it in a derived ODD will be vanishingly small.

[sydb]

But ODD is a system for writing and customizing schema languages, not just TEI. If MEI uses <defaultVal>, and MEI customizer may want to remove it. Also, customization chaining may mean I want to customize the SILLYWALK customizaiton of TEI, but it uses <defaultVal>, and I don’t want it.

Yes, vanishingly small, but for consistency’s sake, I still think it should be there. So I would probably agree to low priority, but not to saying it should not be done.

[martindholmes]

Fair enough. Let's start digging through the Stylesheets, then!

[joeytakeda]

Can I close this ticket and open a new one in the stylesheet repo?

[sydb]

Let's start digging through the Stylesheets, then!

Might be a little premature; may want a few others from Council to weigh in, no?

[joeytakeda]

(PS: I am happy to help with work on the stylesheets/submit a PR if that helps with anything.)

…

On Mon, Sep 10, 2018 at 5:16 PM Syd Bauman ***@***.***> wrote: Let's start digging through the Stylesheets, then! Might be a little premature; may want a few others from Council to weigh in, no? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1807 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQ2K-0oIObivtmtZkl9pQi8yokclhVUwks5uZwD3gaJpZM4WSNr7> .

[lb42]

Thinking about this again, I remain unconvinced. Changing the default value for an attribute from one value to another is a plausible change, which is supported by the current ODD language. But removing the existence of any default value at all seems to me to be a change of a different order, which should properly be done by redefining the attribute. Making the <defaultVal> element combinable is a fudge: you are only doing it so that you can say @mode=delete : you'd never want to say @mode=change or replace because the element is empty.

Need I say that I am opposed to removing <defaultVal> ? A project, including the TEI, can choose not to use it, but it's useful; in DTD land (I know, I know) it's very widely used indeed.

[martindholmes]

My main concern is that the Guidelines stop using it. The fact that it's used in DTD-land is part of my problem; ever since DTDs and their defaultVals we've had this problem of people "using" attributes without knowing about it. It's mad. It mixes schemas with document instances in a way which is pernicious. Schemas should validate, not contribute to, documents, especially in a world where multiple schemas are routinely used to validate a single document.

[sydb]

in DTD land … it's very widely used indeed.

To the detriment of all, some would say.

(Not me — although I think the drawbacks of default values outweigh the advantages, I do see the advantages.)

If you’re argument, @lb42, is “the @mode of <defaultVal> would only have "add" and "delete", therefore it would not be like other @modes and we should reject it”, then note that the @mode of <memberOf> only has "add" and "delete". (And <classes> only has "change" and "replace".)

[joeytakeda]

I think @sydb's point still stands: ODD is a schema writing system, so unless the TEI decides to deprecate and stop supporting <defaultVal> completely (which I'm not at all suggesting), then I think there ought to be a way to get rid of them from your own schema if you don't want them.

But removing the existence of any default value at all seems to me to be a change of a different order, which should properly be done by redefining the attribute

I'm a bit confused about this. What criteria are in place that determines whether or not something is allowed to be combinable or requires redefinition?

[lb42]

I entirely agree that there should be a way of removing defaultValk if you dont want it. I think that if you do thatr, though, you are changing something pretty fundamental about the attribute, so it's not unreasonable to require you to redefine it. But I can see I am in a minority in this opinion so I'll pipe down.

[martindholmes]

Two questions for Council to answer:

1. Should there be ANY <defaultVal>s in the TEI Guidelines specifications? (I say no, because most ordinary users don't know about them, don't understand their perniciousness, and don't realize they're "using" attributes they've never heard of. Nuke them. This does NOT mean removing the defaultVal mechanism from ODD; let anyone use it who wants to.)

2. Should <defaultVal> be a member of att.combinable, so that if someone wants to delete it, they can easily do so? (I say don't bother, because it's going to require a fair amount of work in the Stylesheets, and especially if our own <defaultVal>s are gone, hardly anyone will need it. Also there's a perfectly good method of getting rid of it as shown above, although it is a bit verbose.)

If Council agrees with me on #1, then after deleting all our own <defaultVal>s, we'll need to make sure we add good tests for handling of <defaultVal> to the Stylesheets tests, because it won't be tested automatically in our build process.

[sydb]

And, while we’re considering questions about <defaultVal>:

0. Should we change the semantics of <defaultVal> from what it means now (“validator: if this attribute is not supplied, please pretend that this value was supplied instead”) to merely a processing hint.

If we make change (0) we do not have to worry about @martindholmes ’s (1).

P.S. If we do not make change (0), then I am mildly in favour of both (1) and (2). (I think we should try to avoid using <defaultVal> in the Guidelines unless we make change (0), but recognize that there may be cases where we really want to keep it; and I think we should make putting <defaultVal> into att.combinable a “yeah, we’d like to do that someday, but it is low-priority” task.)

[lb42]

I have not changed my opinion on this and simply reiterating points previously raised does not encourage me to do so. But for the record: (1) by all means remove existing usages of defaultVal in the schema if they are so annoying. (2) do not change its existing class membership. And (3) do not monkey with its existing semantics.

[jamescummings]

In face to face 2019-05-07 Council decides to have defaultVal claim membership of att.combinable. Discussions of what we should do about defaultVal generally, and changing its semantics are interesting but the Council has made no decision on those.

[martindholmes]

Added <defaultVal> to att.combinable per Council's instructions in commit #306d5a5dc..797c3c5.

[martindholmes]

And removed it from att.deprecated in commit 80c7519 because att.combinable is a member of att.deprecated anyway.

[martindholmes]

This is implemented, but I've also raised the required issue in the Stylesheets to make sure we get it processed correctly:

TEIC/Stylesheets#393