mode="clone" on *Spec

[jamescummings]

As mentioned, admittedly offhandedly, in https://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1710&L=TEI-L&D=0&P=89325 I think it would be good to have an elementSpec be able to say "I'm just like this other element, except for this or that thing that I've changed". Presumably the option should be available for other *Spec elements as well.

i.e. Let's say I want to create a new my:specialBibl element I could

1) create a new elementSpec copying all of the existing bibl elementSpec but modifying those things that I want, except this doesn't really show its inheritance, nor do I get and new modifications in tei:bibl added at a later date. 2) modify tei:bibl, putting it into 'my' namespace as when I'm doing a supersetting change to an element, except while this shows its original and I get new modifications, it also removes tei:bibl from my schema. I want both tei:bibl and my:specialBibl

Instead I propose a new value of @mode which is 'clone' or 'cloneAndChange' or something like that where I can create a new *Spec and it does not remove the existing item that I point to. To do this @ident couldn't be the name of the original element (as it is the element to be created) so there needs to be a mechanism to say "I am a copy of that element over there". I propose @source and that this is done by pointing at the spec file of the element that you are modifying. i.e. http://www.tei-c.org/release/xml/tei/odd/Source/Specs/bibl.xml

e.g.

<elementSpec ident="specialBibl" 
source="http://www.tei-c.org/release/xml/tei/odd/Source/Specs/bibl.xml" 
mode="clone" 
ns="http://james.blushingbunny.net/ns.html">

<!-- new desc -->
   <desc>My special bibl</desc>

<!-- new superset content model -->
<content>
 <alternate minOccurs="0" maxOccurs="unbounded">
  <textNode/>
  <classRef key="model.biblPart"/>
  <classRef key="model.phrase"/>
  <classRef key="model.MyNewClassOfThings"/>
 </alternate>
</content>
</elementSpec>

A SchemaTron rule could be added that if @mode='clone' then there must be a @source attribute.

[martindholmes]

A very naive question: what if you want to keep both elements, so you want tei:bibl and bunny:bibl. What should happen if they both have the same @ident?

[jamescummings]

Hrmmmm, yes, keeping both is precisely what I'm proposing. What happens now when two things have the same ident? I think the later overwrites the former? The same thing should happen though we could make it an error for it to have the same ident as the thing it is cloning?

[lb42]

As I said before if you want a new thing in a new namespace, define it with mode=add. Since it's in a new namespace the value of @ident need not be unique. Whether the current stylesheets will cope remains to be seen however

[jamescummings]

@lb42 I think you are still missing the point. If I do:

<elementSpec ident="specialBibl" 
mode="add" 
ns="http://james.blushingbunny.net/ns.html">
<!-- full elementSpec needed here -->
</elementSpec>

I have to provide the full details of an elementSpec, do I not? What I'm saying is I think it would be useful to be able to say "make me a new element, based entirely on that one over there, but with this one small change". The TEI could use this internally as well. For example:

<elementSpec ident="persName" 
source="http://www.tei-c.org/release/xml/tei/odd/Source/Specs/name.xml" 
mode="clone" 
ns="http://www.tei-c.org/ns/1.0">
<altIdent>persName</altIdent>
<!-- include just the things that are different like desc, persName automagically gets name's content model, etc. -->
<desc>contains a proper noun or proper-noun phrase referring to a person, possibly including one or more of the person's forenames, surnames, honorifics, added names, etc.</desc>
</elementSpec>

Currently we must define persName entirely separately as a new element. If we had mode="clone" then we could do so explicitly saying that persName is just a specialisation of name. If the content model of name changed in a later update to the TEI, then it would automagically for persName as well. If I do mode="change" and altIdent then the original 'name' element will disappear. If I do mode="add" I'm creating a new element from scratch. If I do mode="replace" I'm overwriting the existing one. Or is there another way to do this that I'm not aware of? (Always a distinct possibility! ;-))

[lb42]

No, I think your description is correct. I was just responding to the suggestion that @ident need be unique.

[martindholmes]

From a mechanical point of view, I think there's an issue in trying to clone something by referring to it by its ident, when idents need not be unique. If you have three elements with the same ident in different namespaces, how do I specify which one I want to replace or clone?

[jamescummings]

That is why I am suggesting that we use a URI rather than its ident. We refer to the elementSpec of the thing that we are cloning using @source. I believe this may already work for some *Spec objects with regard to using mode="change". i.e. that you could use @source to point to the thing which you are changing and thus mix elementSpecs from previous versions of the TEI. But I may be wrong about that and I'm not saying that is a good idea (since it is not using 'change' properly I don't think since it isn't overwriting the original). Unless you all think change is a better way to do it. With my view of what clone means, what is the difference between:

<elementSpec ident="persName" 
source="http://www.tei-c.org/release/xml/tei/odd/Source/Specs/name.xml" 
mode="clone" 
ns="http://www.tei-c.org/ns/1.0">
<altIdent>persName</altIdent>
<!-- include just the things that are different like desc, persName automagically gets name's content model, etc. -->
<desc>contains a proper noun or proper-noun phrase referring to a person, possibly including one or more of the person's forenames, surnames, honorifics, added names, etc.</desc>
</elementSpec>

and

<elementSpec ident="persName" 
source="http://www.tei-c.org/release/xml/tei/odd/Source/Specs/name.xml" 
mode="change" 
ns="http://www.tei-c.org/ns/1.0">
<altIdent>persName</altIdent>
<!-- include just the things that are different like desc, persName automagically gets name's content model, etc. -->
<desc>contains a proper noun or proper-noun phrase referring to a person, possibly including one or more of the person's forenames, surnames, honorifics, added names, etc.</desc>
</elementSpec>

?

I think that is a mis-use of change since change in other places means that it becomes the new version of the thing, whereas with clone the original is still there untouched, it is just a template for the new thing.

[raffazizzi]

I suggest to write a schematron rule to make @ns required (and not matching <schemaSpec>'s @ns) when @mode = 'clone'

[peterstadler]

How about redefining/specifying the behavior of <elementSpec ident="some:element" source="some:source" mode="change" >, i.e. the combination of @change and @source, to be cloning? If you wanted to adjust the element name and/or namespace we could be doing this via <altIdent>

[jamescummings]

So having source and mode=change would mean take a copy of this and change it? I'm not adverse to that as long as there is a shortcut way to say that the source is whatever the source of the current ODD is.

[sydb]

F2F sub group thinks that overall this is a good idea. Our current working suggestion is that att.identified would gain a new @cloneOf attribute, whose value is syntactically whatever @ident is. A clone would be indicated by an @mode of "clone". When this occurs @cloneOf is required (and it is not allowed otherwise), and the object to be cloned is found by searching the current source (ancestor-or-self::*[@source][1]) for the att.identified element of the same type as self:: that has an @ident that matches self::*/@cloneOf. We’re currently thinking that att.identified would modify @mode so that it has the new value "clone" (which is not one of the values defined by att.combinable, and for good reason: <valDesc>, <valItem>, and <valList> cannot be clones, as they do not bear @ident.)

[martinascholger]

The work should be done in a new branch. The corresponding stylesheets ticket should be tested on that branch, then put it into dev