customizing the TEI?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

customizing the TEI?

Birnbaum, David J
Dear TEI-L,

23.3.1.5 Class Modification
(http://www.tei-c.org/release/doc/tei-p5-doc/en/html/USE.html#MDMDCL)
gives an example of adding <eg> to the class att.typed, that is, modifying
the schema to permit @type and related attributes on the TEI <eg> element.
The example reads:

<elementSpec ident="eg" module="tagdocs"
 mode="change" ns="http://www.example.com/ns/nonTEI">
 <classes mode="change">
  <memberOf key="att.typed"/>
 </classes>
</elementSpec>

In order to do this, the Guidelines move <eg> out of the TEI namespace. I
think I understand why the Guidelines do this: <eg type="stuff"> would not
be valid against TEI all, and therefore wouldn't be "clean". But there's
no such thing in TEI as a pure <eg> element: there's an <eg> element in
the TEI namespace and, if we create it, a new <eg> element not in the TEI
namespace. As far as I can tell, though, this isn't a modification of an
<eg> element, since there's no such thing; the real name of an element is
informed by both the namespace and the local name. <eg> in the TEI
namespace and <eg> not in the TEI namespace are completely different
elements.

Have I, then, understood correctly that the preceding example is not
modifying the <eg> element in the TEI namespace, the one that's valid in
TEI all, and that what it's doing instead is deleting that element and
creating a new element with the same local name but in a different
namespace? That is, that what's being changed (specified in the "change"
value of the @mode attribute) is not definition of the <eg> element, but
the thing to which the @ident value of "eg" points? Clarification welcome!

Best,

David
Reply | Threaded
Open this post in threaded view
|

Re: customizing the TEI?

Lou Burnard-6

I am not sure that I fully understand the issue David is getting at here. In earlier discussions we've made it clear enough that usage of emotive terms like "pure" and "clean" with respect to TEI modifications is to be deprecated, so I don't really see what the assertion "there is no such thing as a pure <eg> element" is meant to be countering.

The point of the example is that if you make a sufficiently large modification to an existing TEI definition, then the resulting element should belong to a different namespace. Whether adding new attributes is "sufficiently large" is something we could usefully discuss, but let's assume for the moment that we agree that it is. The existing definition for <eg> (the untyped one) is here being used as a template for a new definition, but (and this is perhaps what David is getting at) maybe we shouldn't assume that this means it's also disappearing. Maybe the result of this modification should be to permit in a schema both <tei:eg> (without @type) and <new:eg> (with @type). But I'm pretty sure it doesn't work like that...


On 20/10/17 17:07, Birnbaum, David J wrote:
Dear TEI-L,

23.3.1.5 Class Modification
(http://www.tei-c.org/release/doc/tei-p5-doc/en/html/USE.html#MDMDCL)
gives an example of adding <eg> to the class att.typed, that is, modifying
the schema to permit @type and related attributes on the TEI <eg> element.
The example reads:

<elementSpec ident="eg" module="tagdocs"
 mode="change" ns="http://www.example.com/ns/nonTEI">
 <classes mode="change">
  <memberOf key="att.typed"/>
 </classes>
</elementSpec>

In order to do this, the Guidelines move <eg> out of the TEI namespace. I
think I understand why the Guidelines do this: <eg type="stuff"> would not
be valid against TEI all, and therefore wouldn't be "clean". But there's
no such thing in TEI as a pure <eg> element: there's an <eg> element in
the TEI namespace and, if we create it, a new <eg> element not in the TEI
namespace. As far as I can tell, though, this isn't a modification of an
<eg> element, since there's no such thing; the real name of an element is
informed by both the namespace and the local name. <eg> in the TEI
namespace and <eg> not in the TEI namespace are completely different
elements.

Have I, then, understood correctly that the preceding example is not
modifying the <eg> element in the TEI namespace, the one that's valid in
TEI all, and that what it's doing instead is deleting that element and
creating a new element with the same local name but in a different
namespace? That is, that what's being changed (specified in the "change"
value of the @mode attribute) is not definition of the <eg> element, but
the thing to which the @ident value of "eg" points? Clarification welcome!

Best,

David

Reply | Threaded
Open this post in threaded view
|

Re: customizing the TEI?

Martin Holmes
Hi all,

I think David's point is a good one, in view of the fact that
@mode="change" on the elementSpec. In view of the fact that we're
"changing" something rather than adding something new, my intuitive
thought would be that the original tei:eg would go away. My reading is
that the processor should get the original <eg> element from the TEI
namespace and change its namespace to the new one.

I wonder what happens if you change @mode to "add".

That @mode attribute really is a bit of a nightmare -- see the
discussion on this Stylesheets bug:

<https://github.com/TEIC/Stylesheets/issues/272>

I'm beginning to think it should be abandoned and replaced with a better
mechanism.

Cheers,
Martin

On 2017-10-20 12:59 PM, Lou Burnard wrote:

> I am not sure that I fully understand the issue David is getting at
> here. In earlier discussions we've made it clear enough that usage of
> emotive terms like "pure" and "clean" with respect to TEI modifications
> is to be deprecated, so I don't really see what the assertion "there is
> no such thing as a pure <eg> element" is meant to be countering.
>
> The point of the example is that if you make a sufficiently large
> modification to an existing TEI definition, then the resulting element
> should belong to a different namespace. Whether adding new attributes is
> "sufficiently large" is something we could usefully discuss, but let's
> assume for the moment that we agree that it is. The existing definition
> for <eg> (the untyped one) is here being used as a template for a new
> definition, but (and this is perhaps what David is getting at) maybe we
> shouldn't assume that this means it's also disappearing. Maybe the
> result of this modification should be to permit in a schema both
> <tei:eg> (without @type) and <new:eg> (with @type). But I'm pretty sure
> it doesn't work like that...
>
>
> On 20/10/17 17:07, Birnbaum, David J wrote:
>> Dear TEI-L,
>>
>> 23.3.1.5 Class Modification
>> (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/USE.html#MDMDCL)
>> gives an example of adding <eg> to the class att.typed, that is, modifying
>> the schema to permit @type and related attributes on the TEI <eg> element.
>> The example reads:
>>
>> <elementSpec ident="eg" module="tagdocs"
>>   mode="change" ns="http://www.example.com/ns/nonTEI">
>>   <classes mode="change">
>>    <memberOf key="att.typed"/>
>>   </classes>
>> </elementSpec>
>>
>> In order to do this, the Guidelines move <eg> out of the TEI namespace. I
>> think I understand why the Guidelines do this: <eg type="stuff"> would not
>> be valid against TEI all, and therefore wouldn't be "clean". But there's
>> no such thing in TEI as a pure <eg> element: there's an <eg> element in
>> the TEI namespace and, if we create it, a new <eg> element not in the TEI
>> namespace. As far as I can tell, though, this isn't a modification of an
>> <eg> element, since there's no such thing; the real name of an element is
>> informed by both the namespace and the local name. <eg> in the TEI
>> namespace and <eg> not in the TEI namespace are completely different
>> elements.
>>
>> Have I, then, understood correctly that the preceding example is not
>> modifying the <eg> element in the TEI namespace, the one that's valid in
>> TEI all, and that what it's doing instead is deleting that element and
>> creating a new element with the same local name but in a different
>> namespace? That is, that what's being changed (specified in the "change"
>> value of the @mode attribute) is not definition of the <eg> element, but
>> the thing to which the @ident value of "eg" points? Clarification welcome!
>>
>> Best,
>>
>> David
>
Reply | Threaded
Open this post in threaded view
|

Re: customizing the TEI?

Birnbaum, David J
Dear TEI-L,

Thanks, Lou and Martin, for the quick responses. I think you've both
understood the issue I was raising, viz., whether creating an element in a
new namespace that shares a local name with an existing TEI element is
properly considered a "change" of the TEI element.

With respect to details, Lou writes:

> In earlier discussions we've made it clear enough that usage of emotive
>terms
> like "pure" and "clean" with respect to TEI modifications is to be
>deprecated,
> so I don't really see what the assertion "there is no such thing as a
>pure <eg>
> element" is meant to be countering.

This is sort of a digression, but since it led to a misunderstanding, I'll
try to clarify what I meant. First, the definition of "clean" has changed
over the history of the TEI. In an article that responded to the use of
the term in P3, one author suggested alternative terms ("superset" and
"subset") that were were self-documenting and that avoided the vernacular
emotional valence of "clean" and "unclean". See section 5.1.2 of
http://www.obdurodon.org/djb/tei-crit/ (the article was published in
Markup Languages: Theory and Practice, Volume 3 Issue 1, December 2000,
Pages 17-53). This suggestion appears not to have caught on (perhaps the
author of the article was alone in considering them an improvement), so
despite the apparently social deprecation of the term "clean" to which Lou
refers, the Guidelines still say
(http://www.tei-c.org/release/doc/tei-p5-doc/en/html/USE.html):

> We use the term clean modification for the former case, where the set of
>documents
> defined by the modified schema is a proper subset of the set of
>documents defined
> by the unmodified schema. Where this is not the case, that is, where the
>modified
> schema considers valid some documents which the unmodified schema does
>not, we use
> the term unclean modification. Despite this terminology, unclean
>modifications are
> not particularly deprecated, and their use may often be vital to the
>success of a
> project. The concept is introduced solely to distinguish the effects of
>different
> kinds of modification.


Deprecation notwithstanding, unclean is still in use in the Guidelines,
but it has now come to mean only modifications that incorporate
supersetting, a distinction that was not made in P3. In any case, I did
not mean to imply anything emotional by using the term "pure"; what I
meant is that an element has a Qname, and I thought the idea of "changing"
the <eg> element by moving it to a different namespace was confusing
because it's a different element. In other words, "eg" *purely and simply*
isn't meaningful; it's "eg" in the TEI namespace or in a new namespace or
in no namespace, and there is no such thing as pure "eg", that is, "eg"
without either a namespace or the explicit absence of a namespace.
Changing the namespace of an element isn't like changing its content model
by adding a @type attribute; <tei:eg> and <my:eg> are different elements,
and not the same element in a different namespace (which is sort of the
justification for namespaces in the first place). So my question was, as
Lou and Martin both wrote, whether it's correct to say that we're
"changing" <tei:eg> when we create <my:eg> (I think not, but perhaps I've
misunderstood), and what the TEI intends as the fate for <tei:eg> when we
create <my:eg> (I don't know the answer to that, or even whether there is
an answer).

But I'm concerned, beyond that immediate question, also about the
hierarchical ramifications of changes of this sort. If I replace <tei:eg>
with <my:eg> because I've added a @type element, and that change has
justified creating a replacement element in a new namespace, that means
that the content model of all TEI elements that could previously have
contained <tei:eg> have now been changed to permit <my:eg> in place of
<tei:eg>. If that's the case, do they also have to be replaced by elements
in my new namespace, since their content models have changed? If not, why
not? And so on up the tree. In other words, if adding an attribute to a
content model requires us to create an element in a new namespace at a low
level, why doesn't permitting that new element in the content models of
potential parent elements require us, similarly, to create replacement
parent elements in our new namespace, and to do so all the way up?

I realize that this is an annoying question (at least, it annoys me), but
it isn't meant to be argumentative. I find the Guidelines confusing about
change vs replacement, although I think I can understand what is meant if
we think of it as changing not the element, but the thing to which the
@ident attribute points. If initially @ident pointed to an element called
<eg> in the TEI namespace, but adding an @ns attribute I make it point to
something different. If I'm not the only person to find the meaning of
"change" confusing (and Martin's response suggests that I may not be),
perhaps that merits clarification. And I don't understand the hierarchical
implications, that is, why, when a change of namespace is required at the
lowest level, the ramifications of that change in the content model one
level up, and so on, do not similarly require a change of namespace.
Ultimately, I'm left with a sense that subsetting the TEI is easy, but
extending it is not. And, because extension is sometimes desirable in the
context of a particular project, I wonder whether it might be possible to
make extending the TEI less complex.

Best,

David

__

On 10/20/17, 5:49 PM, "TEI (Text Encoding Initiative) public discussion
list on behalf of Martin Holmes" <[hidden email] on behalf of
[hidden email]> wrote:

>Hi all,
>
>I think David's point is a good one, in view of the fact that
>@mode="change" on the elementSpec. In view of the fact that we're
>"changing" something rather than adding something new, my intuitive
>thought would be that the original tei:eg would go away. My reading is
>that the processor should get the original <eg> element from the TEI
>namespace and change its namespace to the new one.
>
>I wonder what happens if you change @mode to "add".
>
>That @mode attribute really is a bit of a nightmare -- see the
>discussion on this Stylesheets bug:
>
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>om%2FTEIC%2FStylesheets%2Fissues%2F272&data=01%7C01%7Cdjbpitt%40PITT.EDU%7
>C9bdde0748816491f380f08d5180469a6%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1&s
>data=1XxzJXrxN6QqM8d6BfwTgVnu7SU13dFZpj0Te5t47zo%3D&reserved=0>
>
>I'm beginning to think it should be abandoned and replaced with a better
>mechanism.
>
>Cheers,
>Martin
>
>On 2017-10-20 12:59 PM, Lou Burnard wrote:
>> I am not sure that I fully understand the issue David is getting at
>> here. In earlier discussions we've made it clear enough that usage of
>> emotive terms like "pure" and "clean" with respect to TEI modifications
>> is to be deprecated, so I don't really see what the assertion "there is
>> no such thing as a pure <eg> element" is meant to be countering.
>>
>> The point of the example is that if you make a sufficiently large
>> modification to an existing TEI definition, then the resulting element
>> should belong to a different namespace. Whether adding new attributes
>>is
>> "sufficiently large" is something we could usefully discuss, but let's
>> assume for the moment that we agree that it is. The existing definition
>> for <eg> (the untyped one) is here being used as a template for a new
>> definition, but (and this is perhaps what David is getting at) maybe we
>> shouldn't assume that this means it's also disappearing. Maybe the
>> result of this modification should be to permit in a schema both
>> <tei:eg> (without @type) and <new:eg> (with @type). But I'm pretty sure
>> it doesn't work like that...
>>
>>
>> On 20/10/17 17:07, Birnbaum, David J wrote:
>>> Dear TEI-L,
>>>
>>> 23.3.1.5 Class Modification
>>>
>>>(https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.tei
>>>-c.org%2Frelease%2Fdoc%2Ftei-p5-doc%2Fen%2Fhtml%2FUSE.html%23MDMDCL&data
>>>=01%7C01%7Cdjbpitt%40PITT.EDU%7C9bdde0748816491f380f08d5180469a6%7C9ef9f
>>>489e0a04eeb87cc3a526112fd0d%7C1&sdata=PeAuNJtpxqBxbMqYzfFvatw9kVbR18N4qJ
>>>sbBX64Sck%3D&reserved=0)
>>> gives an example of adding <eg> to the class att.typed, that is,
>>>modifying
>>> the schema to permit @type and related attributes on the TEI <eg>
>>>element.
>>> The example reads:
>>>
>>> <elementSpec ident="eg" module="tagdocs"
>>>   mode="change"
>>>ns="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
>>>example.com%2Fns%2FnonTEI&data=01%7C01%7Cdjbpitt%40PITT.EDU%7C9bdde07488
>>>16491f380f08d5180469a6%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1&sdata=kpIj
>>>lMM2ojsWmu2jR0VFgB%2F1HSVox8fI3G4ownR0doc%3D&reserved=0">
>>>   <classes mode="change">
>>>    <memberOf key="att.typed"/>
>>>   </classes>
>>> </elementSpec>
>>>
>>> In order to do this, the Guidelines move <eg> out of the TEI
>>>namespace. I
>>> think I understand why the Guidelines do this: <eg type="stuff"> would
>>>not
>>> be valid against TEI all, and therefore wouldn't be "clean". But
>>>there's
>>> no such thing in TEI as a pure <eg> element: there's an <eg> element in
>>> the TEI namespace and, if we create it, a new <eg> element not in the
>>>TEI
>>> namespace. As far as I can tell, though, this isn't a modification of
>>>an
>>> <eg> element, since there's no such thing; the real name of an element
>>>is
>>> informed by both the namespace and the local name. <eg> in the TEI
>>> namespace and <eg> not in the TEI namespace are completely different
>>> elements.
>>>
>>> Have I, then, understood correctly that the preceding example is not
>>> modifying the <eg> element in the TEI namespace, the one that's valid
>>>in
>>> TEI all, and that what it's doing instead is deleting that element and
>>> creating a new element with the same local name but in a different
>>> namespace? That is, that what's being changed (specified in the
>>>"change"
>>> value of the @mode attribute) is not definition of the <eg> element,
>>>but
>>> the thing to which the @ident value of "eg" points? Clarification
>>>welcome!
>>>
>>> Best,
>>>
>>> David
>>
Reply | Threaded
Open this post in threaded view
|

Re: customizing the TEI?

Lou Burnard-6
In reply to this post by Martin Holmes



On 20/10/17 22:49, Martin Holmes wrote:
Hi all,

I think David's point is a good one, in view of the fact that @mode="change" on the elementSpec. In view of the fact that we're "changing" something rather than adding something new, my intuitive thought would be that the original tei:eg would go away. My reading is that the processor should get the original <eg> element from the TEI namespace and change its namespace to the new one.

Yes, I share this belief. And retract my earlier speculation that you might still have the old definition.


I wonder what happens if you change @mode to "add".


I would expect you to get two eg elements, one in the new namespace and one not. Except that unless your new definition includes all the necessary specs for class membership etc. it probably wont appear anywhere in the tree, so it won't show up in your schema.

That @mode attribute really is a bit of a nightmare -- see the discussion on this Stylesheets bug:

<https://github.com/TEIC/Stylesheets/issues/272>

I'm beginning to think it should be abandoned and replaced with a better mechanism.


This seems a bit drastic. As I've noted on the ticket, the underlying problem is most likely that erroneous or meaningless usages are not being flagged by the ODD processor, which is definitely confusing. The behaviour suggested by the table at the end of http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TD.html#TDbuild doesn't seem to have been implemented.
But I think the intended meanings of the various values for @mode are pretty clearly defined all the same.



Cheers,
Martin

On 2017-10-20 12:59 PM, Lou Burnard wrote:
I am not sure that I fully understand the issue David is getting at here. In earlier discussions we've made it clear enough that usage of emotive terms like "pure" and "clean" with respect to TEI modifications is to be deprecated, so I don't really see what the assertion "there is no such thing as a pure <eg> element" is meant to be countering.

The point of the example is that if you make a sufficiently large modification to an existing TEI definition, then the resulting element should belong to a different namespace. Whether adding new attributes is "sufficiently large" is something we could usefully discuss, but let's assume for the moment that we agree that it is. The existing definition for <eg> (the untyped one) is here being used as a template for a new definition, but (and this is perhaps what David is getting at) maybe we shouldn't assume that this means it's also disappearing. Maybe the result of this modification should be to permit in a schema both <tei:eg> (without @type) and <new:eg> (with @type). But I'm pretty sure it doesn't work like that...


On 20/10/17 17:07, Birnbaum, David J wrote:
Dear TEI-L,

23.3.1.5 Class Modification
(http://www.tei-c.org/release/doc/tei-p5-doc/en/html/USE.html#MDMDCL)
gives an example of adding <eg> to the class att.typed, that is, modifying
the schema to permit @type and related attributes on the TEI <eg> element.
The example reads:

<elementSpec ident="eg" module="tagdocs"
  mode="change" ns="http://www.example.com/ns/nonTEI">
  <classes mode="change">
   <memberOf key="att.typed"/>
  </classes>
</elementSpec>

In order to do this, the Guidelines move <eg> out of the TEI namespace. I
think I understand why the Guidelines do this: <eg type="stuff"> would not
be valid against TEI all, and therefore wouldn't be "clean". But there's
no such thing in TEI as a pure <eg> element: there's an <eg> element in
the TEI namespace and, if we create it, a new <eg> element not in the TEI
namespace. As far as I can tell, though, this isn't a modification of an
<eg> element, since there's no such thing; the real name of an element is
informed by both the namespace and the local name. <eg> in the TEI
namespace and <eg> not in the TEI namespace are completely different
elements.

Have I, then, understood correctly that the preceding example is not
modifying the <eg> element in the TEI namespace, the one that's valid in
TEI all, and that what it's doing instead is deleting that element and
creating a new element with the same local name but in a different
namespace? That is, that what's being changed (specified in the "change"
value of the @mode attribute) is not definition of the <eg> element, but
the thing to which the @ident value of "eg" points? Clarification welcome!

Best,

David


Reply | Threaded
Open this post in threaded view
|

Re: customizing the TEI?

Lou Burnard-6
In reply to this post by Birnbaum, David J

David raises several important issues here, which require longer treatment than seems appropriate in a  message to TEI-L, so I'm going to content myself with just making a few comments.

First, yes, the notion of TEI conformance and associated concepts as currently presented in the Guidelines, though somewhat improved since the first release of P5, are by no means satisfactory. Just take a look at the github issue tracker for evidence. In an attempt to kick start a revision of that chapter, I am hoping to present a paper on the topic at the forthcoming TEI Members Meeting (I think it's not too late to book!).

In that paper, I attempt to address inter alia what I would like to call the "turtles all the way up" problem which David mentions in his post. If you modify an element so severely (and reasonable opinion may disagree on this) that it really ought to be placed in a different namespace, and if, further, you modify the parent elements of your mutant, shouldn't those elements also be moved to a non-TEI name space? and their parents too by the same logic? My response is to point out that the way to ensure that your mutant gets included in the document tree is not to modify all of its potential parents, but simply to ensure that it retains its model class memberships intact. TEI content models are defined (mostly) in terms of model classes rather than explicit element references precisely to permit modifiability within the law. An element x whose content model is "any member of model class y" remains conformant whatever the actual membership of model class y may be.

In general, however, I think we just have to live with the fact that a judgment call will always be needed to  assess the degree of TEI conformance of a TEI extension, as opposed to a TEI subset (a distinction I have stolen from David's original article). But then so is any other such assessment, even if no modification has been applied!

Lou

Reply | Threaded
Open this post in threaded view
|

Re: customizing the TEI?

James Cummings-5

Hi Lou,


With your solution to the 'turtles all the way up' problem you suggest that while class membership is potentially fluid, the use of classes in content models is the mechanism by which that fluidity is controlled.  If I create a new element my:specialBibliographicEntry and add it to model.biblLike then it appears everywhere that model.biblLike is used. Since elements with model.biblLike in their content models specify this as a class it is not considered a change to the content model, and thus the chain of mutations stops there.  Great, I do, for the record, agree wholeheartedly.  However, this has a necessary correlate does it not? That if I "change" tei:bibl in some supersetting manner, then to be good the namespace must also change, as a result we currently get a new element my:bibl and tei:bibl vanishes. (I believe this is what happens in the processing, right?). If the new element is a member of the same model classes, all those that have that class in  a content model get this new my:bibl element. Fine.  But, where tei:bibl appears in content models directly, should it get that new element automagically? Or should all those elements suddenly lose tei:bibl? Or do we get tei:bibl there and my:bibl elsewhere? If I add it manually back to those elements' content models, then shouldn't they then go into a recursive 'turtles all the way up' state? Take for example msItemStruct which gets tei:bibl directly. If I subset tei:bibl then it should remain. If I superset tei:bibl, then it should have a new namespace, and thus vanish (perhaps without my knowledge?) from msItemStruct? I believe that is what the processing currently does (happy to be corrected), but I can see an argument that maybe if I'm doing such a supersetting modification I should not be allowed to "change" it but must "replace" it instead? Similarly, having a way to say "make me this new element that is exactly like that one but with this one change" seems useful?


This of course highlights that content models should only be provided by reference to classes, and in a continuation of our original class war we should provide new content models to all elements whose content model currently calls an element directly. Even where this means creating classes for every single element? (In which case what is the difference between the reference to a class and to an element?) I can see why some people might think this extreme, but I'm not in principle against this idea. What we do now is a pragmatic middle ground, we use classes where we have groups of elements that make sense to be in a class because they are used in more than one place, or have some semantic grouping, and then for very particular cases we use the elements directly in the content model.  I'm not sure this pragmatism is actually desirable since it doesn't really follow clear rules, and I don't like magic. ;-)


Gearing up for class warfare,

James 


--

Dr James Cummings, [hidden email]

School of English Literature, Language, and Linguistics, Newcastle University


From: TEI (Text Encoding Initiative) public discussion list <[hidden email]> on behalf of Lou Burnard <[hidden email]>
Sent: 22 October 2017 16:58:11
To: [hidden email]
Subject: Re: customizing the TEI?
 

David raises several important issues here, which require longer treatment than seems appropriate in a  message to TEI-L, so I'm going to content myself with just making a few comments.

First, yes, the notion of TEI conformance and associated concepts as currently presented in the Guidelines, though somewhat improved since the first release of P5, are by no means satisfactory. Just take a look at the github issue tracker for evidence. In an attempt to kick start a revision of that chapter, I am hoping to present a paper on the topic at the forthcoming TEI Members Meeting (I think it's not too late to book!).

In that paper, I attempt to address inter alia what I would like to call the "turtles all the way up" problem which David mentions in his post. If you modify an element so severely (and reasonable opinion may disagree on this) that it really ought to be placed in a different namespace, and if, further, you modify the parent elements of your mutant, shouldn't those elements also be moved to a non-TEI name space? and their parents too by the same logic? My response is to point out that the way to ensure that your mutant gets included in the document tree is not to modify all of its potential parents, but simply to ensure that it retains its model class memberships intact. TEI content models are defined (mostly) in terms of model classes rather than explicit element references precisely to permit modifiability within the law. An element x whose content model is "any member of model class y" remains conformant whatever the actual membership of model class y may be.

In general, however, I think we just have to live with the fact that a judgment call will always be needed to  assess the degree of TEI conformance of a TEI extension, as opposed to a TEI subset (a distinction I have stolen from David's original article). But then so is any other such assessment, even if no modification has been applied!

Lou

Reply | Threaded
Open this post in threaded view
|

Re: customizing the TEI?

Lou Burnard-6
In reply to this post by Lou Burnard-6



On 23/10/17 13:15, James Cummings wrote:
... if I "change" tei:bibl in some supersetting manner, then to be good the namespace must also change, as a result we currently get a new element my:bibl and tei:bibl vanishes. (I believe this is what happens in the processing, right?). 

Yes, if you have specified @mode="change". If OTOH you specify your new element with @mode="add", you will have both your:bibl and tei:bibl  if that's what you want.

If the new element is a member of the same model classes, all those that have that class in  a content model get this new my:bibl element. Fine.  But, where tei:bibl appears in content models directly, should it get that new element automagically? Or should all those elements suddenly lose tei:bibl?

I think that if there are instances where tei:bibl is explicitly mentioned in a content model, rather than being referenced via a class, you must expect it to be no longer available there if tei:bibl is changed to new:bibl, just as certainly as it will cease to be available if you say @mode="delete".  Certainly I don't think such specific references should be changed to use new:bibl.

 Or do we get tei:bibl there and my:bibl elsewhere? 

I think not.

If I add it manually back to those elements' content models, then shouldn't they then go into a recursive 'turtles all the way up' state? Take for example msItemStruct which gets tei:bibl directly. If I subset tei:bibl then it should remain. If I superset tei:bibl, then it should have a new namespace, and thus vanish (perhaps without my knowledge?) from msItemStruct? I believe that is what the processing currently does (happy to be corrected), but I can see an argument that maybe if I'm doing such a supersetting modification I should not be allowed to "change" it but must "replace" it instead? 

Biting back the impulse to say "serves you right for using msItemStruct", I would comment only that using mode=replace rather than mode=change won't help.  In either case, the existing tei:bibl will disappear: the difference is that @mode=replace requires you to specify *everything* you want to say about your new:bibl whereas using @mode=change will retain any parts of the original definition that you don't specify


Similarly, having a way to say "make me this new element that is exactly like that one but with this one change" seems useful?
@mode="change" you mean?



This of course highlights that content models should only be provided by reference to classes, and in a continuation of our original class war we should provide new content models to all elements whose content model currently calls an element directly. Even where this means creating classes for every single element? (In which case what is the difference between the reference to a class and to an element?) I can see why some people might think this extreme, but I'm not in principle against this idea. What we do now is a pragmatic middle ground, we use classes where we have groups of elements that make sense to be in a class because they are used in more than one place, or have some semantic grouping, and then for very particular cases we use the elements directly in the content model.  I'm not sure this pragmatism is actually desirable since it doesn't really follow clear rules, and I don't like magic. ;-)


Gearing up for class warfare,

Bring it on...


L


James


--

Dr James Cummings, [hidden email]

School of English Literature, Language, and Linguistics, Newcastle University

________________________________
From: TEI (Text Encoding Initiative) public discussion list [hidden email] on behalf of Lou Burnard [hidden email]
Sent: 22 October 2017 16:58:11
To: [hidden email]
Subject: Re: customizing the TEI?


David raises several important issues here, which require longer treatment than seems appropriate in a  message to TEI-L, so I'm going to content myself with just making a few comments.

First, yes, the notion of TEI conformance and associated concepts as currently presented in the Guidelines, though somewhat improved since the first release of P5, are by no means satisfactory. Just take a look at the github issue tracker for evidence. In an attempt to kick start a revision of that chapter, I am hoping to present a paper on the topic at the forthcoming TEI Members Meeting (I think it's not too late to book!).

In that paper, I attempt to address inter alia what I would like to call the "turtles all the way up" problem which David mentions in his post. If you modify an element so severely (and reasonable opinion may disagree on this) that it really ought to be placed in a different namespace, and if, further, you modify the parent elements of your mutant, shouldn't those elements also be moved to a non-TEI name space? and their parents too by the same logic? My response is to point out that the way to ensure that your mutant gets included in the document tree is not to modify all of its potential parents, but simply to ensure that it retains its model class memberships intact. TEI content models are defined (mostly) in terms of model classes rather than explicit element references precisely to permit modifiability within the law. An element x whose content model is "any member of model class y" remains conformant whatever the actual membership of model class y may be.

In general, however, I think we just have to live with the fact that a judgment call will always be needed to  assess the degree of TEI conformance of a TEI extension, as opposed to a TEI subset (a distinction I have stolen from David's original article). But then so is any other such assessment, even if no modification has been applied!

Lou



Reply | Threaded
Open this post in threaded view
|

Re: customizing the TEI?

James Cummings-5




Best wishes,

James 


--

Dr James Cummings, [hidden email]

School of English Literature, Language, and Linguistics, Newcastle University




From: TEI (Text Encoding Initiative) public discussion list <[hidden email]> on behalf of Lou Burnard <[hidden email]>
Sent: 23 October 2017 14:43
To: [hidden email]
Subject: Re: customizing the TEI?
 



On 23/10/17 13:15, James Cummings wrote:
... if I "change" tei:bibl in some supersetting manner, then to be good the namespace must also change, as a result we currently get a new element my:bibl and tei:bibl vanishes. (I believe this is what happens in the processing, right?). 

Yes, if you have specified @mode="change". If OTOH you specify your new element with @mode="add", you will have both your:bibl and tei:bibl  if that's what you want.

If the new element is a member of the same model classes, all those that have that class in  a content model get this new my:bibl element. Fine.  But, where tei:bibl appears in content models directly, should it get that new element automagically? Or should all those elements suddenly lose tei:bibl?

I think that if there are instances where tei:bibl is explicitly mentioned in a content model, rather than being referenced via a class, you must expect it to be no longer available there if tei:bibl is changed to new:bibl, just as certainly as it will cease to be available if you say @mode="delete".  Certainly I don't think such specific references should be changed to use new:bibl.

 Or do we get tei:bibl there and my:bibl elsewhere? 

I think not.

If I add it manually back to those elements' content models, then shouldn't they then go into a recursive 'turtles all the way up' state? Take for example msItemStruct which gets tei:bibl directly. If I subset tei:bibl then it should remain. If I superset tei:bibl, then it should have a new namespace, and thus vanish (perhaps without my knowledge?) from msItemStruct? I believe that is what the processing currently does (happy to be corrected), but I can see an argument that maybe if I'm doing such a supersetting modification I should not be allowed to "change" it but must "replace" it instead? 

Biting back the impulse to say "serves you right for using msItemStruct", I would comment only that using mode=replace rather than mode=change won't help.  In either case, the existing tei:bibl will disappear: the difference is that @mode=replace requires you to specify *everything* you want to say about your new:bibl whereas using @mode=change will retain any parts of the original definition that you don't specify


Similarly, having a way to say "make me this new element that is exactly like that one but with this one change" seems useful?
@mode="change" you mean?

This of course highlights that content models should only be provided by reference to classes, and in a continuation of our original class war we should provide new content models to all elements whose content model currently calls an element directly. Even where this means creating classes for every single element? (In which case what is the difference between the reference to a class and to an element?) I can see why some people might think this extreme, but I'm not in principle against this idea. What we do now is a pragmatic middle ground, we use classes where we have groups of elements that make sense to be in a class because they are used in more than one place, or have some semantic grouping, and then for very particular cases we use the elements directly in the content model.  I'm not sure this pragmatism is actually desirable since it doesn't really follow clear rules, and I don't like magic. ;-)


Gearing up for class warfare,

Bring it on...


L


James


--

Dr James Cummings, [hidden email]

School of English Literature, Language, and Linguistics, Newcastle University

________________________________
From: TEI (Text Encoding Initiative) public discussion list [hidden email] on behalf of Lou Burnard [hidden email]
Sent: 22 October 2017 16:58:11
To: [hidden email]
Subject: Re: customizing the TEI?


David raises several important issues here, which require longer treatment than seems appropriate in a  message to TEI-L, so I'm going to content myself with just making a few comments.

First, yes, the notion of TEI conformance and associated concepts as currently presented in the Guidelines, though somewhat improved since the first release of P5, are by no means satisfactory. Just take a look at the github issue tracker for evidence. In an attempt to kick start a revision of that chapter, I am hoping to present a paper on the topic at the forthcoming TEI Members Meeting (I think it's not too late to book!).

In that paper, I attempt to address inter alia what I would like to call the "turtles all the way up" problem which David mentions in his post. If you modify an element so severely (and reasonable opinion may disagree on this) that it really ought to be placed in a different namespace, and if, further, you modify the parent elements of your mutant, shouldn't those elements also be moved to a non-TEI name space? and their parents too by the same logic? My response is to point out that the way to ensure that your mutant gets included in the document tree is not to modify all of its potential parents, but simply to ensure that it retains its model class memberships intact. TEI content models are defined (mostly) in terms of model classes rather than explicit element references precisely to permit modifiability within the law. An element x whose content model is "any member of model class y" remains conformant whatever the actual membership of model class y may be.

In general, however, I think we just have to live with the fact that a judgment call will always be needed to  assess the degree of TEI conformance of a TEI extension, as opposed to a TEI subset (a distinction I have stolen from David's original article). But then so is any other such assessment, even if no modification has been applied!

Lou



Reply | Threaded
Open this post in threaded view
|

Re: customizing the TEI?

James Cummings-5
In reply to this post by Lou Burnard-6

Oops, and now with the reply I really wanted to include: 


>>Similarly, having a way to say "make me this new element that is exactly like that 
>>one but with this one change" seems useful?
>@mode="change" you mean?


No, because that would change the one that is there.  What I was suggesting was more something like mode="duplicateAndChange", where I could take tei:bibl, change a few things about it, and have a new otherwise identical element. tei:bibl would remain unchanged.


Best wishes,

James 


--

Dr James Cummings, [hidden email]

School of English Literature, Language, and Linguistics, Newcastle University


From: James Cummings
Sent: 23 October 2017 16:03:59
To: [hidden email]; Lou Burnard
Subject: Re: customizing the TEI?
 




Best wishes,

James 


--

Dr James Cummings, [hidden email]

School of English Literature, Language, and Linguistics, Newcastle University




From: TEI (Text Encoding Initiative) public discussion list <[hidden email]> on behalf of Lou Burnard <[hidden email]>
Sent: 23 October 2017 14:43
To: [hidden email]
Subject: Re: customizing the TEI?
 



On 23/10/17 13:15, James Cummings wrote:
... if I "change" tei:bibl in some supersetting manner, then to be good the namespace must also change, as a result we currently get a new element my:bibl and tei:bibl vanishes. (I believe this is what happens in the processing, right?). 

Yes, if you have specified @mode="change". If OTOH you specify your new element with @mode="add", you will have both your:bibl and tei:bibl  if that's what you want.

If the new element is a member of the same model classes, all those that have that class in  a content model get this new my:bibl element. Fine.  But, where tei:bibl appears in content models directly, should it get that new element automagically? Or should all those elements suddenly lose tei:bibl?

I think that if there are instances where tei:bibl is explicitly mentioned in a content model, rather than being referenced via a class, you must expect it to be no longer available there if tei:bibl is changed to new:bibl, just as certainly as it will cease to be available if you say @mode="delete".  Certainly I don't think such specific references should be changed to use new:bibl.

 Or do we get tei:bibl there and my:bibl elsewhere? 

I think not.

If I add it manually back to those elements' content models, then shouldn't they then go into a recursive 'turtles all the way up' state? Take for example msItemStruct which gets tei:bibl directly. If I subset tei:bibl then it should remain. If I superset tei:bibl, then it should have a new namespace, and thus vanish (perhaps without my knowledge?) from msItemStruct? I believe that is what the processing currently does (happy to be corrected), but I can see an argument that maybe if I'm doing such a supersetting modification I should not be allowed to "change" it but must "replace" it instead? 

Biting back the impulse to say "serves you right for using msItemStruct", I would comment only that using mode=replace rather than mode=change won't help.  In either case, the existing tei:bibl will disappear: the difference is that @mode=replace requires you to specify *everything* you want to say about your new:bibl whereas using @mode=change will retain any parts of the original definition that you don't specify


Similarly, having a way to say "make me this new element that is exactly like that one but with this one change" seems useful?
@mode="change" you mean?

This of course highlights that content models should only be provided by reference to classes, and in a continuation of our original class war we should provide new content models to all elements whose content model currently calls an element directly. Even where this means creating classes for every single element? (In which case what is the difference between the reference to a class and to an element?) I can see why some people might think this extreme, but I'm not in principle against this idea. What we do now is a pragmatic middle ground, we use classes where we have groups of elements that make sense to be in a class because they are used in more than one place, or have some semantic grouping, and then for very particular cases we use the elements directly in the content model.  I'm not sure this pragmatism is actually desirable since it doesn't really follow clear rules, and I don't like magic. ;-)


Gearing up for class warfare,

Bring it on...


L


James


--

Dr James Cummings, [hidden email]

School of English Literature, Language, and Linguistics, Newcastle University

________________________________
From: TEI (Text Encoding Initiative) public discussion list [hidden email] on behalf of Lou Burnard [hidden email]
Sent: 22 October 2017 16:58:11
To: [hidden email]
Subject: Re: customizing the TEI?


David raises several important issues here, which require longer treatment than seems appropriate in a  message to TEI-L, so I'm going to content myself with just making a few comments.

First, yes, the notion of TEI conformance and associated concepts as currently presented in the Guidelines, though somewhat improved since the first release of P5, are by no means satisfactory. Just take a look at the github issue tracker for evidence. In an attempt to kick start a revision of that chapter, I am hoping to present a paper on the topic at the forthcoming TEI Members Meeting (I think it's not too late to book!).

In that paper, I attempt to address inter alia what I would like to call the "turtles all the way up" problem which David mentions in his post. If you modify an element so severely (and reasonable opinion may disagree on this) that it really ought to be placed in a different namespace, and if, further, you modify the parent elements of your mutant, shouldn't those elements also be moved to a non-TEI name space? and their parents too by the same logic? My response is to point out that the way to ensure that your mutant gets included in the document tree is not to modify all of its potential parents, but simply to ensure that it retains its model class memberships intact. TEI content models are defined (mostly) in terms of model classes rather than explicit element references precisely to permit modifiability within the law. An element x whose content model is "any member of model class y" remains conformant whatever the actual membership of model class y may be.

In general, however, I think we just have to live with the fact that a judgment call will always be needed to  assess the degree of TEI conformance of a TEI extension, as opposed to a TEI subset (a distinction I have stolen from David's original article). But then so is any other such assessment, even if no modification has been applied!

Lou



Reply | Threaded
Open this post in threaded view
|

Re: customizing the TEI?

Lou Burnard-6
In reply to this post by Lou Burnard-6

Ah, OK. So you want maybe @mode="clone" ?

Sounds like a job for a feature request....



On 23/10/17 16:06, James Cummings wrote:
Oops, and now with the reply I really wanted to include:


Similarly, having a way to say "make me this new element that is exactly like that
one but with this one change" seems useful?
@mode="change" you mean?

No, because that would change the one that is there.  What I was suggesting was more something like mode="duplicateAndChange", where I could take tei:bibl, change a few things about it, and have a new otherwise identical element. tei:bibl would remain unchanged.


Best wishes,

James


--

Dr James Cummings, [hidden email]

School of English Literature, Language, and Linguistics, Newcastle University

________________________________
From: James Cummings
Sent: 23 October 2017 16:03:59
To: [hidden email]; Lou Burnard
Subject: Re: customizing the TEI?





Best wishes,

James


--

Dr James Cummings, [hidden email]

School of English Literature, Language, and Linguistics, Newcastle University


________________________________
From: TEI (Text Encoding Initiative) public discussion list [hidden email] on behalf of Lou Burnard [hidden email]
Sent: 23 October 2017 14:43
To: [hidden email]
Subject: Re: customizing the TEI?



On 23/10/17 13:15, James Cummings wrote:

... if I "change" tei:bibl in some supersetting manner, then to be good the namespace must also change, as a result we currently get a new element my:bibl and tei:bibl vanishes. (I believe this is what happens in the processing, right?).

Yes, if you have specified @mode="change". If OTOH you specify your new element with @mode="add", you will have both your:bibl and tei:bibl  if that's what you want.


If the new element is a member of the same model classes, all those that have that class in  a content model get this new my:bibl element. Fine.  But, where tei:bibl appears in content models directly, should it get that new element automagically? Or should all those elements suddenly lose tei:bibl?

I think that if there are instances where tei:bibl is explicitly mentioned in a content model, rather than being referenced via a class, you must expect it to be no longer available there if tei:bibl is changed to new:bibl, just as certainly as it will cease to be available if you say @mode="delete".  Certainly I don't think such specific references should be changed to use new:bibl.


 Or do we get tei:bibl there and my:bibl elsewhere?

I think not.


If I add it manually back to those elements' content models, then shouldn't they then go into a recursive 'turtles all the way up' state? Take for example msItemStruct which gets tei:bibl directly. If I subset tei:bibl then it should remain. If I superset tei:bibl, then it should have a new namespace, and thus vanish (perhaps without my knowledge?) from msItemStruct? I believe that is what the processing currently does (happy to be corrected), but I can see an argument that maybe if I'm doing such a supersetting modification I should not be allowed to "change" it but must "replace" it instead?

Biting back the impulse to say "serves you right for using msItemStruct", I would comment only that using mode=replace rather than mode=change won't help.  In either case, the existing tei:bibl will disappear: the difference is that @mode=replace requires you to specify *everything* you want to say about your new:bibl whereas using @mode=change will retain any parts of the original definition that you don't specify



Similarly, having a way to say "make me this new element that is exactly like that one but with this one change" seems useful?

@mode="change" you mean?


This of course highlights that content models should only be provided by reference to classes, and in a continuation of our original class war we should provide new content models to all elements whose content model currently calls an element directly. Even where this means creating classes for every single element? (In which case what is the difference between the reference to a class and to an element?) I can see why some people might think this extreme, but I'm not in principle against this idea. What we do now is a pragmatic middle ground, we use classes where we have groups of elements that make sense to be in a class because they are used in more than one place, or have some semantic grouping, and then for very particular cases we use the elements directly in the content model.  I'm not sure this pragmatism is actually desirable since it doesn't really follow clear rules, and I don't like magic. ;-)


Gearing up for class warfare,


Bring it on...


L



James


--

Dr James Cummings, [hidden email][hidden email]

School of English Literature, Language, and Linguistics, Newcastle University

________________________________
From: TEI (Text Encoding Initiative) public discussion list [hidden email][hidden email] on behalf of Lou Burnard [hidden email][hidden email]
Sent: 22 October 2017 16:58:11
To: [hidden email][hidden email]
Subject: Re: customizing the TEI?


David raises several important issues here, which require longer treatment than seems appropriate in a  message to TEI-L, so I'm going to content myself with just making a few comments.

First, yes, the notion of TEI conformance and associated concepts as currently presented in the Guidelines, though somewhat improved since the first release of P5, are by no means satisfactory. Just take a look at the github issue tracker for evidence. In an attempt to kick start a revision of that chapter, I am hoping to present a paper on the topic at the forthcoming TEI Members Meeting (I think it's not too late to book!).

In that paper, I attempt to address inter alia what I would like to call the "turtles all the way up" problem which David mentions in his post. If you modify an element so severely (and reasonable opinion may disagree on this) that it really ought to be placed in a different namespace, and if, further, you modify the parent elements of your mutant, shouldn't those elements also be moved to a non-TEI name space? and their parents too by the same logic? My response is to point out that the way to ensure that your mutant gets included in the document tree is not to modify all of its potential parents, but simply to ensure that it retains its model class memberships intact. TEI content models are defined (mostly) in terms of model classes rather than explicit element references precisely to permit modifiability within the law. An element x whose content model is "any member of model class y" remains conformant whatever the actual membership of model class y may be.

In general, however, I think we just have to live with the fact that a judgment call will always be needed to  assess the degree of TEI conformance of a TEI extension, as opposed to a TEI subset (a distinction I have stolen from David's original article). But then so is any other such assessment, even if no modification has been applied!

Lou






Reply | Threaded
Open this post in threaded view
|

Re: customizing the TEI?

Martin Holmes
Let's not have another value of @mode until we can figure out exactly
what we mean by the existing ones. :-)

On 2017-10-23 08:14 AM, Lou Burnard wrote:

> Ah, OK. So you want maybe @mode="clone" ?
>
> Sounds like a job for a feature request....
>
>
>
> On 23/10/17 16:06, James Cummings wrote:
>> Oops, and now with the reply I really wanted to include:
>>
>>
>>>> Similarly, having a way to say "make me this new element that is exactly like that
>>>> one but with this one change" seems useful?
>>> @mode="change" you mean?
>>
>> No, because that would change the one that is there.  What I was suggesting was more something like mode="duplicateAndChange", where I could take tei:bibl, change a few things about it, and have a new otherwise identical element. tei:bibl would remain unchanged.
>>
>>
>> Best wishes,
>>
>> James
>>
>>
>> --
>>
>> Dr James Cummings,[hidden email]
>>
>> School of English Literature, Language, and Linguistics, Newcastle University
>>
>> ________________________________
>> From: James Cummings
>> Sent: 23 October 2017 16:03:59
>> To:[hidden email]; Lou Burnard
>> Subject: Re: customizing the TEI?
>>
>>
>>
>>
>>
>> Best wishes,
>>
>> James
>>
>>
>> --
>>
>> Dr James Cummings,[hidden email]
>>
>> School of English Literature, Language, and Linguistics, Newcastle University
>>
>>
>> ________________________________
>> From: TEI (Text Encoding Initiative) public discussion list<[hidden email]>  on behalf of Lou Burnard<[hidden email]>
>> Sent: 23 October 2017 14:43
>> To:[hidden email]
>> Subject: Re: customizing the TEI?
>>
>>
>>
>> On 23/10/17 13:15, James Cummings wrote:
>>
>> ... if I "change" tei:bibl in some supersetting manner, then to be good the namespace must also change, as a result we currently get a new element my:bibl and tei:bibl vanishes. (I believe this is what happens in the processing, right?).
>>
>> Yes, if you have specified @mode="change". If OTOH you specify your new element with @mode="add", you will have both your:bibl and tei:bibl  if that's what you want.
>>
>>
>> If the new element is a member of the same model classes, all those that have that class in  a content model get this new my:bibl element. Fine.  But, where tei:bibl appears in content models directly, should it get that new element automagically? Or should all those elements suddenly lose tei:bibl?
>>
>> I think that if there are instances where tei:bibl is explicitly mentioned in a content model, rather than being referenced via a class, you must expect it to be no longer available there if tei:bibl is changed to new:bibl, just as certainly as it will cease to be available if you say @mode="delete".  Certainly I don't think such specific references should be changed to use new:bibl.
>>
>>
>>   Or do we get tei:bibl there and my:bibl elsewhere?
>>
>> I think not.
>>
>>
>> If I add it manually back to those elements' content models, then shouldn't they then go into a recursive 'turtles all the way up' state? Take for example msItemStruct which gets tei:bibl directly. If I subset tei:bibl then it should remain. If I superset tei:bibl, then it should have a new namespace, and thus vanish (perhaps without my knowledge?) from msItemStruct? I believe that is what the processing currently does (happy to be corrected), but I can see an argument that maybe if I'm doing such a supersetting modification I should not be allowed to "change" it but must "replace" it instead?
>>
>> Biting back the impulse to say "serves you right for using msItemStruct", I would comment only that using mode=replace rather than mode=change won't help.  In either case, the existing tei:bibl will disappear: the difference is that @mode=replace requires you to specify *everything* you want to say about your new:bibl whereas using @mode=change will retain any parts of the original definition that you don't specify
>>
>>
>>
>> Similarly, having a way to say "make me this new element that is exactly like that one but with this one change" seems useful?
>>
>> @mode="change" you mean?
>>
>>
>> This of course highlights that content models should only be provided by reference to classes, and in a continuation of our original class war we should provide new content models to all elements whose content model currently calls an element directly. Even where this means creating classes for every single element? (In which case what is the difference between the reference to a class and to an element?) I can see why some people might think this extreme, but I'm not in principle against this idea. What we do now is a pragmatic middle ground, we use classes where we have groups of elements that make sense to be in a class because they are used in more than one place, or have some semantic grouping, and then for very particular cases we use the elements directly in the content model.  I'm not sure this pragmatism is actually desirable since it doesn't really follow clear rules, and I don't like magic. ;-)
>>
>>
>> Gearing up for class warfare,
>>
>>
>> Bring it on...
>>
>>
>> L
>>
>>
>>
>> James
>>
>>
>> --
>>
>> Dr James Cummings,[hidden email]<mailto:[hidden email]>
>>
>> School of English Literature, Language, and Linguistics, Newcastle University
>>
>> ________________________________
>> From: TEI (Text Encoding Initiative) public discussion list<[hidden email]><mailto:[hidden email]>  on behalf of Lou Burnard<[hidden email]><mailto:[hidden email]>
>> Sent: 22 October 2017 16:58:11
>> To:[hidden email]<mailto:[hidden email]>
>> Subject: Re: customizing the TEI?
>>
>>
>> David raises several important issues here, which require longer treatment than seems appropriate in a  message to TEI-L, so I'm going to content myself with just making a few comments.
>>
>> First, yes, the notion of TEI conformance and associated concepts as currently presented in the Guidelines, though somewhat improved since the first release of P5, are by no means satisfactory. Just take a look at the github issue tracker for evidence. In an attempt to kick start a revision of that chapter, I am hoping to present a paper on the topic at the forthcoming TEI Members Meeting (I think it's not too late to book!).
>>
>> In that paper, I attempt to address inter alia what I would like to call the "turtles all the way up" problem which David mentions in his post. If you modify an element so severely (and reasonable opinion may disagree on this) that it really ought to be placed in a different namespace, and if, further, you modify the parent elements of your mutant, shouldn't those elements also be moved to a non-TEI name space? and their parents too by the same logic? My response is to point out that the way to ensure that your mutant gets included in the document tree is not to modify all of its potential parents, but simply to ensure that it retains its model class memberships intact. TEI content models are defined (mostly) in terms of model classes rather than explicit element references precisely to permit modifiability within the law. An element x whose content model is "any member of model class y" remains conformant whatever the actual membership of model class y may be.
>>
>> In general, however, I think we just have to live with the fact that a judgment call will always be needed to  assess the degree of TEI conformance of a TEI extension, as opposed to a TEI subset (a distinction I have stolen from David's original article). But then so is any other such assessment, even if no modification has been applied!
>>
>> Lou
>>
>>
>>
>>
>>
>