valList in ODD

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

valList in ODD

Pietro Liuzzo
Dear all,

is it possible in ODD to constrain the values for an attribute to specific values from the ODD or from the current file without specifying a valList?

For example, 
- how can I limit the values allowed for an attribute to the values of a subset of <catDesc> in my ODD or in the TEI file using that ODD? e.g. I want to limit the allowed values of @type for <incipit> to the values of <catDesc> which are descendants of my category[@xml:id='incipit'] 
- how can I limit in the ODD the allowed values of an attribute with teidata.pointer to the list of available xml:id of a specific element in my file? e.g. I want change/@who to only point to existing editor/@xml:id.

thanks a lot!
Pietro


Pietro Maria Liuzzo (egli/lui,he/him,er/ihn)
cel (DE): +49 (0) 176 61 000 606
Skype: pietro.liuzzo (Quingentole)
ORCID: https://orcid.org/0000-0001-5714-4011
Academia: https://uni-hamburg.academia.edu/PietroMariaLiuzzo






lou
Reply | Threaded
Open this post in threaded view
|

Re: valList in ODD

lou
Yes, in a sense. That is: such constraints are not expressible in all schema languages, and therefore not directly modelled in ODD. But you can add a `<constraintSpec>` to express them by means of a `<constraint>` using the schematron language. This has the advantage that such elements are handled (probably) correctly by the current ODD processing toolset -- they are carried forward into the RelaxNG schema generated from your ODD source. But if you are not using RELAXNG that is cold comfort.

I had thought there was an example of exactly this sort of constraint already in the Guidelines, but I can't find one. In the general case, it's difficult to define a constraint which says @target must point to something which is accessible because the only way of finding out whether e.g. @target="foo" is valid is to try to evaluate "foo". But it makes perfectly good sense to restrict what is considered an acceptable target (e.g. "must begin with # which must be followed by a string that is also the content of some xpath") aas you suggest. When you've written your schematron, I suggest you propose it to the council for an example -- lots of people want to do this kind of thing!

On Wed, 23 Dec 2020 at 07:04, Pietro Liuzzo <[hidden email]> wrote:
Dear all,

is it possible in ODD to constrain the values for an attribute to specific values from the ODD or from the current file without specifying a valList?

For example, 
- how can I limit the values allowed for an attribute to the values of a subset of <catDesc> in my ODD or in the TEI file using that ODD? e.g. I want to limit the allowed values of @type for <incipit> to the values of <catDesc> which are descendants of my category[@xml:id='incipit'] 
- how can I limit in the ODD the allowed values of an attribute with teidata.pointer to the list of available xml:id of a specific element in my file? e.g. I want change/@who to only point to existing editor/@xml:id.

thanks a lot!
Pietro


Pietro Maria Liuzzo (egli/lui,he/him,er/ihn)
cel (DE): +49 (0) 176 61 000 606
Skype: pietro.liuzzo (Quingentole)
ORCID: https://orcid.org/0000-0001-5714-4011
Academia: https://uni-hamburg.academia.edu/PietroMariaLiuzzo






Reply | Threaded
Open this post in threaded view
|

Re: valList in ODD

Pietro Liuzzo
Thanks a lot!

my problem with the constraint is that as far as I know it is only checking something after encoders have done it, while the closed list of values suggests already what is right and prevents errors.

I think, at least for using elements which can be available in the ODD itself (my first example in the previous message), what I would like to propose is more of the kind of a customization or extension of the content model of <valList> alternative to it containing <valItem>s, along with a change to the XSLT to support this.

Just to make up a minimal example, free of a lot of needed baggage, only to try and clarify my point, at the moment I have in my ODD this 

<valList type="closed">
        <valItem ident="Hagiography"/>
        <valItem ident="History"/>
</valList>

and in my taxonomy quite the same stuff

<category>
 <catDesc>Subjects</desc>
  <category>
     <catDesc>Hagiography</catDesc>
   </category>
 <category>
    <catDesc>History</catDesc>
  </category>
</category>

Every time the taxonomy is updated I have to update the ODD, so that the right values are available in the right place. This is not a problem in itself or as a procedure, it is just that I think it could be better. 

For example, if I had a dedicated attribute with datatype teidata.xpath or teidata.pointer on valList, let me call it for now '@fetch', I could use that to say something like

<valList type="closed" fetch="//taxonomy//category[catDesc='Subjects']/category/catDesc"/>

And in the teiodds.xsl I would only have to modify xsl:template[@name="valListChildren"
to look for that and make up a simple list of <value>s from the Xpath in @fetch. 

But I guess this would require my ODD to be built itself on a customization to be valid, as I could not declare this change to valList in the same ODD where I use it (or can I?), which I know is possible, but I do not terribly like, as much as I think it would not be that good to simply do this and adapt a local copy of the xslt to that purpose, because my ODD would then become not reusable. I am happy to be told otherwise, if this is just my misunderstanding. 

I guess I would be interested to know from the lots of people if this kind of thing would be anyhow desirable for now.

Thanks a lot again!

all best
Pietro



Pietro Maria Liuzzo (egli/lui,he/him,er/ihn)
cel (DE): +49 (0) 176 61 000 606
Skype: pietro.liuzzo (Quingentole)
ORCID: https://orcid.org/0000-0001-5714-4011
Academia: https://uni-hamburg.academia.edu/PietroMariaLiuzzo






Il giorno 23 dic 2020, alle ore 11:54, Lou Burnard <[hidden email]> ha scritto:

Yes, in a sense. That is: such constraints are not expressible in all schema languages, and therefore not directly modelled in ODD. But you can add a `<constraintSpec>` to express them by means of a `<constraint>` using the schematron language. This has the advantage that such elements are handled (probably) correctly by the current ODD processing toolset -- they are carried forward into the RelaxNG schema generated from your ODD source. But if you are not using RELAXNG that is cold comfort.

I had thought there was an example of exactly this sort of constraint already in the Guidelines, but I can't find one. In the general case, it's difficult to define a constraint which says @target must point to something which is accessible because the only way of finding out whether e.g. @target="foo" is valid is to try to evaluate "foo". But it makes perfectly good sense to restrict what is considered an acceptable target (e.g. "must begin with # which must be followed by a string that is also the content of some xpath") aas you suggest. When you've written your schematron, I suggest you propose it to the council for an example -- lots of people want to do this kind of thing!

On Wed, 23 Dec 2020 at 07:04, Pietro Liuzzo <[hidden email]> wrote:
Dear all,

is it possible in ODD to constrain the values for an attribute to specific values from the ODD or from the current file without specifying a valList?

For example, 
- how can I limit the values allowed for an attribute to the values of a subset of <catDesc> in my ODD or in the TEI file using that ODD? e.g. I want to limit the allowed values of @type for <incipit> to the values of <catDesc> which are descendants of my category[@xml:id='incipit'] 
- how can I limit in the ODD the allowed values of an attribute with teidata.pointer to the list of available xml:id of a specific element in my file? e.g. I want change/@who to only point to existing editor/@xml:id.

thanks a lot!
Pietro


Pietro Maria Liuzzo (egli/lui,he/him,er/ihn)
cel (DE): +49 (0) 176 61 000 606
Skype: pietro.liuzzo (Quingentole)
ORCID: https://orcid.org/0000-0001-5714-4011
Academia: https://uni-hamburg.academia.edu/PietroMariaLiuzzo







Reply | Threaded
Open this post in threaded view
|

Re: valList in ODD

Martin Holmes
In reply to this post by Pietro Liuzzo
Hi Pietro,

I do this in most of my projects, by using a pre-processing XSLT step
which creates or replaces the current valList in the ODD with a new one
constructed from the categories in the taxonomy file. This runs before
the regular ODD processing that builds the schema. You can see an
example XSLT file here:

<https://hcmc.uvic.ca/svn/dvpp/xsl/taxonomies_to_odd_fragments.xsl>

Cheers,
Martin

On 2020-12-22 11:03 p.m., Pietro Liuzzo wrote:

> Dear all,
>
> is it possible in ODD to constrain the values for an attribute to
> specific values from the ODD or from the current file without specifying
> a valList?
>
> For example,
> - how can I limit the values allowed for an attribute to the values of a
> subset of <catDesc> in my ODD or in the TEI file using that ODD? e.g. I
> want to limit the allowed values of @type for <incipit> to the values of
> <catDesc> which are descendants of my category[@xml:id='incipit']
> - how can I limit in the ODD the allowed values of an attribute with
> teidata.pointer to the list of available xml:id of a specific element in
> my file? e.g. I want change/@who to only point to existing editor/@xml:id.
>
> thanks a lot!
> Pietro
>
>
> Pietro Maria Liuzzo (egli/lui,he/him,er/ihn)
> cel (DE): +49 (0) 176 61 000 606
> Skype: pietro.liuzzo (Quingentole)
> ORCID: https://orcid.org/0000-0001-5714-4011
> Academia: https://uni-hamburg.academia.edu/PietroMariaLiuzzo
>
>
>
>
>
>

--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: valList in ODD

Bauman, Syd
In reply to this post by lou
More on the actual question in a minute, but worth pointing out that the TEI Stylesheets will extract your Schematron snippets from your ODD and build a Schematron schema for you even if you don’t use RELAX NG. (You can use Oxgarage, or the binaries in the Stylesheets repo, or run the stylesheet — odds/extract-isosch.xsl — over the compiled ODD by hand. For reasons I have never understood there is no shortcut for this in oXygen, though.)


 
Yes, in a sense. That is: such constraints are not expressible in all schema languages, and therefore not directly modelled in ODD. But you can add a `<constraintSpec>` to express them by means of a `<constraint>` using the schematron language. This has the advantage that such elements are handled (probably) correctly by the current ODD processing toolset -- they are carried forward into the RelaxNG schema generated from your ODD source. But if you are not using RELAXNG that is cold comfort.

I had thought there was an example of exactly this sort of constraint already in the Guidelines, but I can't find one. In the general case, it's difficult to define a constraint which says @target must point to something which is accessible because the only way of finding out whether e.g. @target="foo" is valid is to try to evaluate "foo". But it makes perfectly good sense to restrict what is considered an acceptable target (e.g. "must begin with # which must be followed by a string that is also the content of some xpath") aas you suggest. When you've written your schematron, I suggest you propose it to the council for an example -- lots of people want to do this kind of thing!

Reply | Threaded
Open this post in threaded view
|

Re: valList in ODD

Bauman, Syd
In reply to this post by Martin Holmes
Hi Pietro!

Martin suggests a clever solution, methinks. That said, I do this sort of thing in several places the old fashioned way, just as Lou suggests.

It is actually pretty easy to do if the attribute of interest (in this case @type of <incipit>) is already constrained so that it can only have a single value. (As is the case here.) It can be much harder if multiple values are possible.

Here is a sample of how to do this for direct matching. The second case you raise (verifying a pointer points to a certain kind of element, e.g. that change/@who only points to an <editor>) is not all that different, and I can post about it separately if you like.

Note that I have only tested this code in a rapid, rudimentary way.

  <elementSpec ident="incipit" mode="change" module="msdescription">
    <constraintSpec scheme="schematron" ident="incipit_category_defined">
      <desc>In the PL:xyz project, the <gi>incipit</gi> elements are
      categorized by their <att>type</att> attributes. The value of
      the <att>type</att> attribute should match the content of a
      <gi>catDesc</gi> element which is itself a descendant of the
      <tag>category xml:id="incipit"</tag>.</desc>
      <!--
        The standard closed schema (e.g., RELAX NG) has already
        guaranteed that <incipit> has a @type, and that there is
        only one value in that @type. (It does not guarantee that
        there is no whitespace around that value.)
      -->
      <sch:let name="type" value="normalize-space(@type)"/>
      <sch:let name="cats" value="id('incipit')//tei:catDesc/normalize-space()"/>
      <sch:assert test="$type = $cats">Yo! This &lt;incipit> is
      incorrectly categorized (as <sch:value-of select="$type"/>,
      which is not one of the categorizations permitted (<sch:value-of
      select="string-join($cats,', ')"/>.))</sch:assert>
    </constraintSpec>
  </elementSpec>


From: TEI (Text Encoding Initiative) public discussion list <[hidden email]> on behalf of Martin Holmes <[hidden email]>
Sent: Wednesday, December 23, 2020 08:49
To: [hidden email] <[hidden email]>
Subject: Re: [TEI-L] valList in ODD
 
Hi Pietro,

I do this in most of my projects, by using a pre-processing XSLT step
which creates or replaces the current valList in the ODD with a new one
constructed from the categories in the taxonomy file. This runs before
the regular ODD processing that builds the schema. You can see an
example XSLT file here:

<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhcmc.uvic.ca%2Fsvn%2Fdvpp%2Fxsl%2Ftaxonomies_to_odd_fragments.xsl&amp;data=04%7C01%7Cs.bauman%40NORTHEASTERN.EDU%7C6ef7f8576df34d7651fc08d8a749a8bb%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637443282099620419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=odTAvuFyziezLcF%2FibmUrToL5lcfJeQsO%2FASPVpH3fU%3D&amp;reserved=0>

Cheers,
Martin

On 2020-12-22 11:03 p.m., Pietro Liuzzo wrote:
> Dear all,
>
> is it possible in ODD to constrain the values for an attribute to
> specific values from the ODD or from the current file without specifying
> a valList?
>
> For example,
> - how can I limit the values allowed for an attribute to the values of a
> subset of <catDesc> in my ODD or in the TEI file using that ODD? e.g. I
> want to limit the allowed values of @type for <incipit> to the values of
> <catDesc> which are descendants of my category[@xml:id='incipit']
> - how can I limit in the ODD the allowed values of an attribute with
> teidata.pointer to the list of available xml:id of a specific element in
> my file? e.g. I want change/@who to only point to existing editor/@xml:id.
>
> thanks a lot!
> Pietro
>
>
> Pietro Maria Liuzzo (egli/lui,he/him,er/ihn)
> cel (DE): +49 (0) 176 61 000 606
> Skype: pietro.liuzzo (Quingentole)
> ORCID: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Forcid.org%2F0000-0001-5714-4011&amp;data=04%7C01%7Cs.bauman%40NORTHEASTERN.EDU%7C6ef7f8576df34d7651fc08d8a749a8bb%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637443282099620419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ddcsz0tcIqDSkek6vD3U2TS8uqUKdrP19FMg9GKPnKw%3D&amp;reserved=0
> Academia: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Funi-hamburg.academia.edu%2FPietroMariaLiuzzo&amp;data=04%7C01%7Cs.bauman%40NORTHEASTERN.EDU%7C6ef7f8576df34d7651fc08d8a749a8bb%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637443282099620419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VaTZt3Mxv1uFkhpzLZ4A1HM8IWTNXXy17NwO4fGHM1U%3D&amp;reserved=0
>
>
>
>
>
>

--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: valList in ODD

Bauman, Syd
Clarification: the part that is much harder with multiple values is handling pointers. Handling multiple values that need to match is harder, but not much harder. (Something like “every $t in $types satisfies $t = $cats” after having tokenized the value of @type into $types.)
It is actually pretty easy to do if the attribute of interest (in this case @type of <incipit>) is already constrained so that it can only have a single value. (As is the case here.) It can be much harder if multiple values are possible.



Reply | Threaded
Open this post in threaded view
|

Re: valList in ODD

Pietro Liuzzo
Thanks a lot for all the feedback!

I still think this would be a nice additional possibility, to avoid the transformation and have the values available where needed in the ODD, but I am happy with the transformation solution for now and will certainly add the constraints!

thanks a lot!
Pietro

Pietro Maria Liuzzo (egli/lui,he/him,er/ihn)
cel (DE): +49 (0) 176 61 000 606
Skype: pietro.liuzzo (Quingentole)
ORCID: https://orcid.org/0000-0001-5714-4011
Academia: https://uni-hamburg.academia.edu/PietroMariaLiuzzo






Il giorno 23 dic 2020, alle ore 16:07, Bauman, Syd <[hidden email]> ha scritto:

Clarification: the part that is much harder with multiple values is handling pointers. Handling multiple values that need to match is harder, but not much harder. (Something like “every $t in $types satisfies $t = $cats” after having tokenized the value of @type into $types.)
It is actually pretty easy to do if the attribute of interest (in this case @type of <incipit>) is already constrained so that it can only have a single value. (As is the case here.) It can bemuch harder if multiple values are possible.

Reply | Threaded
Open this post in threaded view
|

Re: valList in ODD

Martin Holmes
Hi all,

The advantage of the transformation approach is that editors get
prompted with available values in e.g. Oxygen. With Schematron, you know
when you got it wrong, but you don't know what the options actually are
without checking the taxonomy.

Cheers,
Martin

On 2020-12-23 8:17 a.m., Pietro Liuzzo wrote:

> Thanks a lot for all the feedback!
>
> I still think this would be a nice additional possibility, to avoid the
> transformation and have the values available where needed in the ODD,
> but I am happy with the transformation solution for now and will
> certainly add the constraints!
>
> thanks a lot!
> Pietro
>
> Pietro Maria Liuzzo (egli/lui,he/him,er/ihn)
> cel (DE): +49 (0) 176 61 000 606
> Skype: pietro.liuzzo (Quingentole)
> ORCID: https://orcid.org/0000-0001-5714-4011
> Academia: https://uni-hamburg.academia.edu/PietroMariaLiuzzo
>
>
>
>
>
>
>> Il giorno 23 dic 2020, alle ore 16:07, Bauman, Syd
>> <[hidden email] <mailto:[hidden email]>> ha scritto:
>>
>> Clarification: the part that is much harder with multiple values is
>> handling pointers. Handling multiple values that need to match is
>> harder, but not much harder. (Something like “every $t in $types
>> satisfies $t = $cats” after having tokenized the value of @type into
>> $types.)
>>
>>     It is actually pretty easy to do if the attribute of interest (in
>>     this case @type of <incipit>) is already constrained so that it
>>     can only have a single value. (As is the case here.) It can
>>     be*much*harder if multiple values are possible.
>

--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]