lost in ODD magic

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

lost in ODD magic

Piotr Banski
Hi all,

My intended change could be described by the following invalid statement
(on the not-so-innocent assumption that ordering inside elementSpec
matters):

<elementSpec ident="form" mode="change" module="dictionaries">
   <attList>
     <attDef ident="type" mode="delete"/>
   </attList>
   <classes mode="change">
     <memberOf key="att.typed" mode="add"/>
   </classes>
</elementSpec>

(I want to remove the independently defined @type and would like to make
<form> a member of att.typed.)


The following is valid (<classes> comes before <attList>) but results in
the deletion of @type from the <form>:

<elementSpec ident="form" mode="change" module="dictionaries">
   <classes mode="change">
     <memberOf key="att.typed" mode="add"/>
   </classes>
   <attList>
     <attDef ident="type" mode="delete"/>
   </attList>
</elementSpec>

If I omit the attList statement then the validator complains about
doubly-defined @type.

How should I go about this, please?

Thanks in advance,

   Piotr
Reply | Threaded
Open this post in threaded view
|

Re: lost in ODD magic

Lou Burnard-6

I haven't checked the code, but I suspect  that by the time it starts deleting attributes from a spec, the ODD processor no longer knows whether the attributes were locally defined or inherited from a class. Which means that what you are trying to do is probably impossible. How sad a state of affairs that is, I am not sure, because I don't quite understand why you want to do it in the first place. What features would being a member of the att.typed class give that the locally defined @type doesn't? If it has features you don't want (e.g. a specific valList)  you can of course delete them from the spec in the usual way. Likewise if class membership brings something additional that you want (e.g. @subtype) the easiest way is going to be define that locally to the elementSpec as well.

And if it's just the design ickiness which is offending your aesthetic sensibilities -- be comforted by the fact that the TEI Council has an ongoing activity targetting removal of all locally-defined-attributes-that-should-be-inherited-from-a-class. Can't remember the ticket number, but it started long ago -- in fact you probably commented on it!


On 27/09/17 10:50, Piotr Bański wrote:
Hi all,

My intended change could be described by the following invalid statement (on the not-so-innocent assumption that ordering inside elementSpec matters):

<elementSpec ident="form" mode="change" module="dictionaries">
  <attList>
    <attDef ident="type" mode="delete"/>
  </attList>
  <classes mode="change">
    <memberOf key="att.typed" mode="add"/>
  </classes>
</elementSpec>

(I want to remove the independently defined @type and would like to make <form> a member of att.typed.)


The following is valid (<classes> comes before <attList>) but results in the deletion of @type from the <form>:

<elementSpec ident="form" mode="change" module="dictionaries">
  <classes mode="change">
    <memberOf key="att.typed" mode="add"/>
  </classes>
  <attList>
    <attDef ident="type" mode="delete"/>
  </attList>
</elementSpec>

If I omit the attList statement then the validator complains about doubly-defined @type.

How should I go about this, please?

Thanks in advance,

  Piotr

Reply | Threaded
Open this post in threaded view
|

Re: lost in ODD magic

Piotr Banski
Thanks, Lou.

Yeah, I wanted to have @subtype, and I wanted to do that *nicely*, not
as a hack -- and adding @subtype manually, given that a class exists
that offers me exactly @type and @subtype together, does seem a bit hackish.

But if you say that I can't do it in the way I intended, I'll just grind
my teeth and hack :-)

Best,

  Piotr

On 09/27/17 12:43, Lou Burnard wrote:

> I haven't checked the code, but I suspect  that by the time it starts
> deleting attributes from a spec, the ODD processor no longer knows
> whether the attributes were locally defined or inherited from a class.
> Which means that what you are trying to do is probably impossible. How
> sad a state of affairs that is, I am not sure, because I don't quite
> understand why you want to do it in the first place. What features would
> being a member of the att.typed class give that the locally defined
> @type doesn't? If it has features you don't want (e.g. a specific
> valList)  you can of course delete them from the spec in the usual way.
> Likewise if class membership brings something additional that you want
> (e.g. @subtype) the easiest way is going to be define that locally to
> the elementSpec as well.
>
> And if it's just the design ickiness which is offending your aesthetic
> sensibilities -- be comforted by the fact that the TEI Council has an
> ongoing activity targetting removal of all
> locally-defined-attributes-that-should-be-inherited-from-a-class. Can't
> remember the ticket number, but it started long ago -- in fact you
> probably commented on it!
>
>
> On 27/09/17 10:50, Piotr Bański wrote:
>> Hi all,
>>
>> My intended change could be described by the following invalid
>> statement (on the not-so-innocent assumption that ordering inside
>> elementSpec matters):
>>
>> <elementSpec ident="form" mode="change" module="dictionaries">
>>   <attList>
>>     <attDef ident="type" mode="delete"/>
>>   </attList>
>>   <classes mode="change">
>>     <memberOf key="att.typed" mode="add"/>
>>   </classes>
>> </elementSpec>
>>
>> (I want to remove the independently defined @type and would like to
>> make <form> a member of att.typed.)
>>
>>
>> The following is valid (<classes> comes before <attList>) but results
>> in the deletion of @type from the <form>:
>>
>> <elementSpec ident="form" mode="change" module="dictionaries">
>>   <classes mode="change">
>>     <memberOf key="att.typed" mode="add"/>
>>   </classes>
>>   <attList>
>>     <attDef ident="type" mode="delete"/>
>>   </attList>
>> </elementSpec>
>>
>> If I omit the attList statement then the validator complains about
>> doubly-defined @type.
>>
>> How should I go about this, please?
>>
>> Thanks in advance,
>>
>>   Piotr
>
Reply | Threaded
Open this post in threaded view
|

Re: lost in ODD magic

Laurent Romary
Would not it be simpler to make a specific feature request concerning form to belong to att.typed (while keeping existing constraints on @type)? It seems consensual enough for it to be rapidly accepted and implemented.
Laurent


Le 27 sept. 2017 à 13:06, Piotr Bański <[hidden email]> a écrit :

Thanks, Lou.

Yeah, I wanted to have @subtype, and I wanted to do that *nicely*, not as a hack -- and adding @subtype manually, given that a class exists that offers me exactly @type and @subtype together, does seem a bit hackish.

But if you say that I can't do it in the way I intended, I'll just grind my teeth and hack :-)

Best,

Piotr

On 09/27/17 12:43, Lou Burnard wrote:
I haven't checked the code, but I suspect  that by the time it starts deleting attributes from a spec, the ODD processor no longer knows whether the attributes were locally defined or inherited from a class. Which means that what you are trying to do is probably impossible. How sad a state of affairs that is, I am not sure, because I don't quite understand why you want to do it in the first place. What features would being a member of the att.typed class give that the locally defined @type doesn't? If it has features you don't want (e.g. a specific valList)  you can of course delete them from the spec in the usual way. Likewise if class membership brings something additional that you want (e.g. @subtype) the easiest way is going to be define that locally to the elementSpec as well.
And if it's just the design ickiness which is offending your aesthetic sensibilities -- be comforted by the fact that the TEI Council has an ongoing activity targetting removal of all locally-defined-attributes-that-should-be-inherited-from-a-class. Can't remember the ticket number, but it started long ago -- in fact you probably commented on it!
On 27/09/17 10:50, Piotr Bański wrote:
Hi all,

My intended change could be described by the following invalid statement (on the not-so-innocent assumption that ordering inside elementSpec matters):

<elementSpec ident="form" mode="change" module="dictionaries">
  <attList>
    <attDef ident="type" mode="delete"/>
  </attList>
  <classes mode="change">
    <memberOf key="att.typed" mode="add"/>
  </classes>
</elementSpec>

(I want to remove the independently defined @type and would like to make <form> a member of att.typed.)


The following is valid (<classes> comes before <attList>) but results in the deletion of @type from the <form>:

<elementSpec ident="form" mode="change" module="dictionaries">
  <classes mode="change">
    <memberOf key="att.typed" mode="add"/>
  </classes>
  <attList>
    <attDef ident="type" mode="delete"/>
  </attList>
</elementSpec>

If I omit the attList statement then the validator complains about doubly-defined @type.

How should I go about this, please?

Thanks in advance,

  Piotr

Laurent Romary
Inria, team ALMAnaCH






Reply | Threaded
Open this post in threaded view
|

Re: lost in ODD magic

Piotr Banski
It's probably because of my idiosyncratic, subconscious and generally
unwarranted reservations concerning speedy resolution of certain feature
requests ;-)

Ticket posted: https://github.com/TEIC/TEI/issues/1688

Best,

   P.


On 09/27/17 13:09, Laurent Romary wrote:

> Would not it be simpler to make a specific feature request concerning
> form to belong to att.typed (while keeping existing constraints on
> @type)? It seems consensual enough for it to be rapidly accepted and
> implemented.
> Laurent
>
>
>> Le 27 sept. 2017 à 13:06, Piotr Bański <[hidden email]
>> <mailto:[hidden email]>> a écrit :
>>
>> Thanks, Lou.
>>
>> Yeah, I wanted to have @subtype, and I wanted to do that *nicely*, not
>> as a hack -- and adding @subtype manually, given that a class exists
>> that offers me exactly @type and @subtype together, does seem a bit
>> hackish.
>>
>> But if you say that I can't do it in the way I intended, I'll just
>> grind my teeth and hack :-)
>>
>> Best,
>>
>> Piotr
>>
>> On 09/27/17 12:43, Lou Burnard wrote:
>>> I haven't checked the code, but I suspect  that by the time it starts
>>> deleting attributes from a spec, the ODD processor no longer knows
>>> whether the attributes were locally defined or inherited from a
>>> class. Which means that what you are trying to do is probably
>>> impossible. How sad a state of affairs that is, I am not sure,
>>> because I don't quite understand why you want to do it in the first
>>> place. What features would being a member of the att.typed class give
>>> that the locally defined @type doesn't? If it has features you don't
>>> want (e.g. a specific valList)  you can of course delete them from
>>> the spec in the usual way. Likewise if class membership brings
>>> something additional that you want (e.g. @subtype) the easiest way is
>>> going to be define that locally to the elementSpec as well.
>>> And if it's just the design ickiness which is offending your
>>> aesthetic sensibilities -- be comforted by the fact that the TEI
>>> Council has an ongoing activity targetting removal of all
>>> locally-defined-attributes-that-should-be-inherited-from-a-class.
>>> Can't remember the ticket number, but it started long ago -- in fact
>>> you probably commented on it!
>>> On 27/09/17 10:50, Piotr Bański wrote:
>>>> Hi all,
>>>>
>>>> My intended change could be described by the following invalid
>>>> statement (on the not-so-innocent assumption that ordering inside
>>>> elementSpec matters):
>>>>
>>>> <elementSpec ident="form" mode="change" module="dictionaries">
>>>>   <attList>
>>>>     <attDef ident="type" mode="delete"/>
>>>>   </attList>
>>>>   <classes mode="change">
>>>>     <memberOf key="att.typed" mode="add"/>
>>>>   </classes>
>>>> </elementSpec>
>>>>
>>>> (I want to remove the independently defined @type and would like to
>>>> make <form> a member of att.typed.)
>>>>
>>>>
>>>> The following is valid (<classes> comes before <attList>) but
>>>> results in the deletion of @type from the <form>:
>>>>
>>>> <elementSpec ident="form" mode="change" module="dictionaries">
>>>>   <classes mode="change">
>>>>     <memberOf key="att.typed" mode="add"/>
>>>>   </classes>
>>>>   <attList>
>>>>     <attDef ident="type" mode="delete"/>
>>>>   </attList>
>>>> </elementSpec>
>>>>
>>>> If I omit the attList statement then the validator complains about
>>>> doubly-defined @type.
>>>>
>>>> How should I go about this, please?
>>>>
>>>> Thanks in advance,
>>>>
>>>>   Piotr
>
> Laurent Romary
> Inria, team ALMAnaCH
> [hidden email] <mailto:[hidden email]>
>
>
>
>
>
>