subtypes of types

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

subtypes of types

Winslow, Sean Michael (sean.winslow@uni-graz.at)

All,

 

If in TEI, if I have a list of @type values:

A, B, C

And @subtypes of those values:

A: A1, A2, A3

B: B4, B5

C: C6, C7

How do I represent the link between the @subtype and @type in the ODD? There doesn’t seem to be an example in the documentation that I can find.

 

<valList type="closed">
        
<valItem ident="A">
         
<desc>A has three subtypes, A1, A2, A3</desc>
        
</valItem>
        
<valItem ident="B">
         
<desc>A has two subtypes, B4, B5</desc>
        
</valItem>
        
<valItem ident="C">
         
<desc>A has two subtypes, C6, C7</desc>
        
</valItem>

</valList>

 

I wpould think I would nest a valList inside the relevant valItem, but this does not seem to be allowed by valItem.

 

<valList type="closed">
        
<valItem ident="A">
         
<desc>A has three subtypes, A1, A2, A3</desc>

<attDef ident="subtype" mode="replace">

<valList type="closed">
              
<valItem ident="A1">
              
</valItem>
              
<valItem ident="A2">
              
</valItem>
              
<valItem ident="A3">
              
</valItem>

</valList>

</attDef>
        
</valItem>

 

Gives : element "attDef" not allowed here; expected the element end-tag or element "altIdent", "desc", "equiv", "gloss", "paramList" or "remarks"

 

What is the intended way to define @subtype lists?

 

Many Thanks,

 

-Sean

 

 

Dr Sean M Winslow
Zentrum für Informationsmodellierung
Austrian Centre for Digital Humanities
Karl-Franzens-Universität Graz
A-8010 Graz | Elisabethstraße 59/III
 
Tel: +43 316 380 5772
[hidden email]
Web: informationsmodellierung.uni-graz.at

 

Reply | Threaded
Open this post in threaded view
|

Re: subtypes of types

Elisa Beshero-Bondar
Hi Sean, 
This is a job for my favorite type of schema language, Schematron, and it's available inside ODD, though a little tricky to write. Schematron allows for definitions of schema rules based on XPath relationships, so you basically write a test to say when your @type attribute is set to "A", the @subtype on the same element must be A1, A2, or A3. I'll post an example or two, here--it helps to see how these are defined in a functioning ODD, and we really need more available examples of Schematron use in ODDs.

Cheers,
Elisa



On Mon, May 28, 2018 at 11:11 AM, Winslow, Sean Michael ([hidden email]) <[hidden email]> wrote:

All,

 

If in TEI, if I have a list of @type values:

A, B, C

And @subtypes of those values:

A: A1, A2, A3

B: B4, B5

C: C6, C7

How do I represent the link between the @subtype and @type in the ODD? There doesn’t seem to be an example in the documentation that I can find.

 

<valList type="closed">
        
<valItem ident="A">
         
<desc>A has three subtypes, A1, A2, A3</desc>
        
</valItem>
        
<valItem ident="B">
         
<desc>A has two subtypes, B4, B5</desc>
        
</valItem>
        
<valItem ident="C">
         
<desc>A has two subtypes, C6, C7</desc>
        
</valItem>

</valList>

 

I wpould think I would nest a valList inside the relevant valItem, but this does not seem to be allowed by valItem.

 

<valList type="closed">
        
<valItem ident="A">
         
<desc>A has three subtypes, A1, A2, A3</desc>

<attDef ident="subtype" mode="replace">

<valList type="closed">
              
<valItem ident="A1">
              
</valItem>
              
<valItem ident="A2">
              
</valItem>
              
<valItem ident="A3">
              
</valItem>

</valList>

</attDef>
        
</valItem>

 

Gives : element "attDef" not allowed here; expected the element end-tag or element "altIdent", "desc", "equiv", "gloss", "paramList" or "remarks"

 

What is the intended way to define @subtype lists?

 

Many Thanks,

 

-Sean

 

 

Dr Sean M Winslow
Zentrum für Informationsmodellierung
Austrian Centre for Digital Humanities
Karl-Franzens-Universität Graz
A-8010 Graz | Elisabethstraße 59/III
 
Tel: +43 316 380 5772
[hidden email]
Web: informationsmodellierung.uni-graz.at

 




--
Elisa Beshero-Bondar, PhD
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA  15601  USA
E-mail:[hidden email]
Development site: http://newtfire.org
Reply | Threaded
Open this post in threaded view
|

Re: subtypes of types

Elisa Beshero-Bondar
Here is a working example of an ODD with some Schematron constraints on attributes used together. This is from a student project in my coding course last spring:

Panning back, here's my whole pile of resources that I share with my students on ODDs (thanks to Syd Bauman for some of these): 

Since my students work on little projects inside of 15 weeks, when they decide to use TEI, their ODDs make nice "starter packs" for introducing various kinds of constraints. 

Hope this helps!
Elisa

On Mon, May 28, 2018 at 11:26 AM, Elisa Beshero-Bondar <[hidden email]> wrote:
Hi Sean, 
This is a job for my favorite type of schema language, Schematron, and it's available inside ODD, though a little tricky to write. Schematron allows for definitions of schema rules based on XPath relationships, so you basically write a test to say when your @type attribute is set to "A", the @subtype on the same element must be A1, A2, or A3. I'll post an example or two, here--it helps to see how these are defined in a functioning ODD, and we really need more available examples of Schematron use in ODDs.

Cheers,
Elisa



On Mon, May 28, 2018 at 11:11 AM, Winslow, Sean Michael ([hidden email]) <[hidden email]> wrote:

All,

 

If in TEI, if I have a list of @type values:

A, B, C

And @subtypes of those values:

A: A1, A2, A3

B: B4, B5

C: C6, C7

How do I represent the link between the @subtype and @type in the ODD? There doesn’t seem to be an example in the documentation that I can find.

 

<valList type="closed">
        
<valItem ident="A">
         
<desc>A has three subtypes, A1, A2, A3</desc>
        
</valItem>
        
<valItem ident="B">
         
<desc>A has two subtypes, B4, B5</desc>
        
</valItem>
        
<valItem ident="C">
         
<desc>A has two subtypes, C6, C7</desc>
        
</valItem>

</valList>

 

I wpould think I would nest a valList inside the relevant valItem, but this does not seem to be allowed by valItem.

 

<valList type="closed">
        
<valItem ident="A">
         
<desc>A has three subtypes, A1, A2, A3</desc>

<attDef ident="subtype" mode="replace">

<valList type="closed">
              
<valItem ident="A1">
              
</valItem>
              
<valItem ident="A2">
              
</valItem>
              
<valItem ident="A3">
              
</valItem>

</valList>

</attDef>
        
</valItem>

 

Gives : element "attDef" not allowed here; expected the element end-tag or element "altIdent", "desc", "equiv", "gloss", "paramList" or "remarks"

 

What is the intended way to define @subtype lists?

 

Many Thanks,

 

-Sean

 

 

Dr Sean M Winslow
Zentrum für Informationsmodellierung
Austrian Centre for Digital Humanities
Karl-Franzens-Universität Graz
A-8010 Graz | Elisabethstraße 59/III
 
Tel: +43 316 380 5772
[hidden email]
Web: informationsmodellierung.uni-graz.at

 




--
Elisa Beshero-Bondar, PhD
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA  15601  USA
E-mail:[hidden email]
Development site: http://newtfire.org



--
Elisa Beshero-Bondar, PhD
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA  15601  USA
E-mail:[hidden email]
Development site: http://newtfire.org
Reply | Threaded
Open this post in threaded view
|

Re: subtypes of types

Winslow, Sean Michael (sean.winslow@uni-graz.at)
Elisa,

Thank you—I will follow the example.


To the general list: it would be nice to see some examples integrated into the documentation.

-Sean

Sean M Winslow

On May 28, 2018, at 17:32, Elisa Beshero-Bondar <[hidden email]> wrote:

Here is a working example of an ODD with some Schematron constraints on attributes used together. This is from a student project in my coding course last spring:

Panning back, here's my whole pile of resources that I share with my students on ODDs (thanks to Syd Bauman for some of these): 

Since my students work on little projects inside of 15 weeks, when they decide to use TEI, their ODDs make nice "starter packs" for introducing various kinds of constraints. 

Hope this helps!
Elisa

On Mon, May 28, 2018 at 11:26 AM, Elisa Beshero-Bondar <[hidden email]> wrote:
Hi Sean, 
This is a job for my favorite type of schema language, Schematron, and it's available inside ODD, though a little tricky to write. Schematron allows for definitions of schema rules based on XPath relationships, so you basically write a test to say when your @type attribute is set to "A", the @subtype on the same element must be A1, A2, or A3. I'll post an example or two, here--it helps to see how these are defined in a functioning ODD, and we really need more available examples of Schematron use in ODDs.

Cheers,
Elisa



On Mon, May 28, 2018 at 11:11 AM, Winslow, Sean Michael ([hidden email]) <[hidden email]> wrote:

All,

 

If in TEI, if I have a list of @type values:

A, B, C

And @subtypes of those values:

A: A1, A2, A3

B: B4, B5

C: C6, C7

How do I represent the link between the @subtype and @type in the ODD? There doesn’t seem to be an example in the documentation that I can find.

 

<valList type="closed">
        
<valItem ident="A">
         
<desc>A has three subtypes, A1, A2, A3</desc>
        
</valItem>
        
<valItem ident="B">
         
<desc>A has two subtypes, B4, B5</desc>
        
</valItem>
        
<valItem ident="C">
         
<desc>A has two subtypes, C6, C7</desc>
        
</valItem>

</valList>

 

I wpould think I would nest a valList inside the relevant valItem, but this does not seem to be allowed by valItem.

 

<valList type="closed">
        
<valItem ident="A">
         
<desc>A has three subtypes, A1, A2, A3</desc>

<attDef ident="subtype" mode="replace">

<valList type="closed">
              
<valItem ident="A1">
              
</valItem>
              
<valItem ident="A2">
              
</valItem>
              
<valItem ident="A3">
              
</valItem>

</valList>

</attDef>
        
</valItem>

 

Gives : element "attDef" not allowed here; expected the element end-tag or element "altIdent", "desc", "equiv", "gloss", "paramList" or "remarks"

 

What is the intended way to define @subtype lists?

 

Many Thanks,

 

-Sean

 

 

Dr Sean M Winslow
Zentrum für Informationsmodellierung
Austrian Centre for Digital Humanities
Karl-Franzens-Universität Graz
A-8010 Graz | Elisabethstraße 59/III
 
Tel: +43 316 380 5772
[hidden email]
Web: informationsmodellierung.uni-graz.at

 




--
Elisa Beshero-Bondar, PhD
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA  15601  USA
E-mail:[hidden email]
Development site: http://newtfire.org



--
Elisa Beshero-Bondar, PhD
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA  15601  USA
E-mail:[hidden email]
Development site: http://newtfire.org

Reply | Threaded
Open this post in threaded view
|

Re: subtypes of types

Elisa Beshero-Bondar

Indeed, I’ll echo that call, Sean! As the TEI is updating its website I know one thing we’ve discussed is an area for the community to post ODDs for various kinds of projects. I don’t know that anything I’ve cobbled together hastily with my students inside a university semester project is exactly exemplary for TEI ODDs for distinct kinds of projects, but it’s functional for examples of how to get a Schematron constraint to work. 


More and more, I think ODDs ought to be something we share in introductory workshops on the TEI—even if it’s just the creation of simple ODDs—because it does help to encourage people to take an intensive survey for themselves of what the TEI has to offer. I had to fight a while to get my Schematron constraints working in ODD, lacking examples. (Like some of us, I suspect, I was impatient of the old Roma tool and used to start with the TEI-All and customize with a lightweight Schematron file to ride on top, but stopped after I took an “advanced” TEI workshop in ODDs. I’m not so sure that ought to be advanced because it gets to look like esoteric knowledge, when its really a beneficial thinking and guided reading exercise for people starting projects. Sure, XPath might be classed as advanced, but ODD doesn’t need it, and one can gently introduce some XPath as one needs it in customizing ODDs for projects.


Cheers,

Elisa



On Mon, May 28, 2018 at 6:13 PM, Winslow, Sean Michael ([hidden email]) <[hidden email]> wrote:
Elisa,

Thank you—I will follow the example.


To the general list: it would be nice to see some examples integrated into the documentation.

-Sean

Sean M Winslow

On May 28, 2018, at 17:32, Elisa Beshero-Bondar <[hidden email]> wrote:

Here is a working example of an ODD with some Schematron constraints on attributes used together. This is from a student project in my coding course last spring:

Panning back, here's my whole pile of resources that I share with my students on ODDs (thanks to Syd Bauman for some of these): 

Since my students work on little projects inside of 15 weeks, when they decide to use TEI, their ODDs make nice "starter packs" for introducing various kinds of constraints. 

Hope this helps!
Elisa

On Mon, May 28, 2018 at 11:26 AM, Elisa Beshero-Bondar <[hidden email]> wrote:
Hi Sean, 
This is a job for my favorite type of schema language, Schematron, and it's available inside ODD, though a little tricky to write. Schematron allows for definitions of schema rules based on XPath relationships, so you basically write a test to say when your @type attribute is set to "A", the @subtype on the same element must be A1, A2, or A3. I'll post an example or two, here--it helps to see how these are defined in a functioning ODD, and we really need more available examples of Schematron use in ODDs.

Cheers,
Elisa



On Mon, May 28, 2018 at 11:11 AM, Winslow, Sean Michael ([hidden email]) <[hidden email]> wrote:

All,

 

If in TEI, if I have a list of @type values:

A, B, C

And @subtypes of those values:

A: A1, A2, A3

B: B4, B5

C: C6, C7

How do I represent the link between the @subtype and @type in the ODD? There doesn’t seem to be an example in the documentation that I can find.

 

<valList type="closed">
        
<valItem ident="A">
         
<desc>A has three subtypes, A1, A2, A3</desc>
        
</valItem>
        
<valItem ident="B">
         
<desc>A has two subtypes, B4, B5</desc>
        
</valItem>
        
<valItem ident="C">
         
<desc>A has two subtypes, C6, C7</desc>
        
</valItem>

</valList>

 

I wpould think I would nest a valList inside the relevant valItem, but this does not seem to be allowed by valItem.

 

<valList type="closed">
        
<valItem ident="A">
         
<desc>A has three subtypes, A1, A2, A3</desc>

<attDef ident="subtype" mode="replace">

<valList type="closed">
              
<valItem ident="A1">
              
</valItem>
              
<valItem ident="A2">
              
</valItem>
              
<valItem ident="A3">
              
</valItem>

</valList>

</attDef>
        
</valItem>

 

Gives : element "attDef" not allowed here; expected the element end-tag or element "altIdent", "desc", "equiv", "gloss", "paramList" or "remarks"

 

What is the intended way to define @subtype lists?

 

Many Thanks,

 

-Sean

 

 

Dr Sean M Winslow
Zentrum für Informationsmodellierung
Austrian Centre for Digital Humanities
Karl-Franzens-Universität Graz
A-8010 Graz | Elisabethstraße 59/III
 
Tel: +43 316 380 5772
[hidden email]
Web: informationsmodellierung.uni-graz.at

 




--
Elisa Beshero-Bondar, PhD
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA  15601  USA
E-mail:[hidden email]
Development site: http://newtfire.org



--
Elisa Beshero-Bondar, PhD
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA  15601  USA
E-mail:[hidden email]
Development site: http://newtfire.org




--
Elisa Beshero-Bondar, PhD
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA  15601  USA
E-mail:[hidden email]
Development site: http://newtfire.org
Reply | Threaded
Open this post in threaded view
|

Re: subtypes of types

Imsieke, Gerrit, le-tex
In reply to this post by Elisa Beshero-Bondar
Hi Elisa and Sean,

Co-occurrence constraints are in fact a job for MY favorite schema
language, and that is Relax NG.

ODD does not (yet) provide native co-occurrence constraints (apart from
embedded Schematron), and this is where I, as a TEI outsider and as a
native Relax NG speaker, recommend filtering a base TEI schema by
another Relax NG schema that permits everything except the type/subtype
constraints.

A benefit of this approach is: In contrast to Schematron (that only
checks validity retroactively), it gives you excellent content
completion in oXygen (versions 19.0 or newer).

This is the NVDL that implements your constraint on top of a TEI allPlus
base schema:
https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_subtypes.nvdl
If you are using oXygen, you can prepend the following xml-model PI to
your document:
<?xml-model
href="https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_subtypes.nvdl"

    type="application/xml"
schematypens="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0"?>

You see in the NVDL that you can refer to any base schema, and this is
another nice property of this approach: It is orthogonal, it does not
depend on knowledge of the inner building blocks (named patterns) of
your base schema. (Schematron, of course, is also orthogonal to the base
schema in that it does not need to know about the names and the
granularity of the base schema patterns.)

This NVDL is an example of the “epischema” approach that I presented at
XML Prague 2017:
http://archive.xmlprague.cz/2017/files/presentations/epischema/index.html#/

The epischema itself is at
https://subversion.le-tex.de/common/schema/tei-cssa/subtypes.rng
Of course it is a bit contrived, but no more so than your example ;)

I’m aware that most TEI users will only start using this approach when
they can generate a complete NVDL with constraints from an ODD
specification. I’m afraid that finding an adequate “grammar constraint”
vocabulary for ODD may already be difficult, let alone generating from
ODD the RNG epischemas that implement these constraints.

Gerrit


On 28.05.2018 17:26, Elisa Beshero-Bondar wrote:

> Hi Sean,
> This is a job for my favorite type of schema language, Schematron, and
> it's available inside ODD, though a little tricky to write. Schematron
> allows for definitions of schema rules based on XPath relationships, so
> you basically write a test to say when your @type attribute is set to
> "A", the @subtype on the same element must be A1, A2, or A3. I'll post
> an example or two, here--it helps to see how these are defined in a
> functioning ODD, and we really need more available examples of
> Schematron use in ODDs.
>
> Cheers,
> Elisa
>
>
>
> On Mon, May 28, 2018 at 11:11 AM, Winslow, Sean Michael
> ([hidden email] <mailto:[hidden email]>)
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     All,____
>
>     __ __
>
>     If in TEI, if I have a list of @type values:____
>
>     A, B, C____
>
>     And @subtypes of those values:____
>
>     A: A1, A2, A3____
>
>     B: B4, B5____
>
>     C: C6, C7____
>
>     How do I represent the link between the @subtype and @type in the
>     ODD? There doesn’t seem to be an example in the documentation that I
>     can find.____
>
>     __ __
>
>     <valListtype="closed">
>     <valItemident="A">
>     <desc>A has three subtypes, A1, A2, A3</desc>
>     </valItem>
>     <valItemident="B">
>     <desc>A has two subtypes, B4, B5</desc>
>     </valItem>
>     <valItemident="C">
>     <desc>A has two subtypes, C6, C7</desc>
>     </valItem>____
>
>     </valList>____
>
>     __ __
>
>     I wpould think I would nest a valList inside the relevant valItem,
>     but this does not seem to be allowed by valItem. ____
>
>     __ __
>
>     <valListtype="closed">
>     <valItemident="A">
>     <desc>A has three subtypes, A1, A2, A3</desc>____
>
>     <attDefident="subtype"mode="replace">____
>
>     <valListtype="closed">
>     <valItemident="A1">
>     </valItem>
>     <valItemident="A2">
>     </valItem>
>     <valItemident="A3">
>     </valItem>____
>
>     </valList>____
>
>     </attDef>
>     </valItem>____
>
>     __ __
>
>     Gives : element "attDef" not allowed here; expected the element
>     end-tag or element "altIdent", "desc", "equiv", "gloss", "paramList"
>     or "remarks"____
>
>     __ __
>
>     What is the intended way to define @subtype lists?____
>
>     __ __
>
>     Many Thanks,____
>
>     __ __
>
>     -Sean____
>
>     __ __
>
>     __ __
>
>     Dr Sean M Winslow
>     Zentrum für Informationsmodellierung
>     Austrian Centre for Digital Humanities
>     Karl-Franzens-Universität Graz
>     A-8010 Graz | Elisabethstraße 59
>     <https://maps.google.com/?q=Elisabethstra%C3%9Fe+59&entry=gmail&source=g>/III
>
>     Tel: +43 316 380 5772
>     eMail: [hidden email] <mailto:[hidden email]>
>     Web: informationsmodellierung.uni-graz.at
>     <http://informationsmodellierung.uni-graz.at>____
>
>     __ __
>
>
>
>
> --
> Elisa Beshero-Bondar, PhD
> Director, Center for the Digital Text | Associate Professor of English
> University of Pittsburgh at Greensburg | Humanities Division
> 150 Finoli Drive
> Greensburg, PA  15601  USA
> E-mail: [hidden email] <mailto:[hidden email]>
> Development site: http://newtfire.org <http://newtfire.org/>

--
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
[hidden email], http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

Geschäftsführer / Managing Directors:
Gerrit Imsieke, Svea Jelonek, Thomas Schmidt
Reply | Threaded
Open this post in threaded view
|

AW: subtypes of types

Winslow, Sean Michael (sean.winslow@uni-graz.at)
Gerrit,

Adding the constraints in Relax NG seems to defeat the purpose of making an ODD, doesn't it? Suddenly, one document does not do it all, and two documents are needed, one to describe the document as TEI and document it, and one to add the constraints to an already-transformed version of the first. It also risks someone getting their hands on and transforming the ODD without the constraints.

Best,

-Sean

Dr Sean M Winslow
Zentrum für Informationsmodellierung
eMail: [hidden email]



-----Ursprüngliche Nachricht-----
Von: TEI (Text Encoding Initiative) public discussion list <[hidden email]> Im Auftrag von Imsieke, Gerrit, le-tex
Gesendet: Dienstag, 29. Mai 2018 01:19
An: [hidden email]
Betreff: Re: subtypes of types

Hi Elisa and Sean,

Co-occurrence constraints are in fact a job for MY favorite schema language, and that is Relax NG.

ODD does not (yet) provide native co-occurrence constraints (apart from embedded Schematron), and this is where I, as a TEI outsider and as a native Relax NG speaker, recommend filtering a base TEI schema by another Relax NG schema that permits everything except the type/subtype constraints.

A benefit of this approach is: In contrast to Schematron (that only checks validity retroactively), it gives you excellent content completion in oXygen (versions 19.0 or newer).

This is the NVDL that implements your constraint on top of a TEI allPlus base schema:
https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_subtypes.nvdl
If you are using oXygen, you can prepend the following xml-model PI to your document:
<?xml-model
href="https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_subtypes.nvdl"

    type="application/xml"
schematypens="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0"?>

You see in the NVDL that you can refer to any base schema, and this is another nice property of this approach: It is orthogonal, it does not depend on knowledge of the inner building blocks (named patterns) of your base schema. (Schematron, of course, is also orthogonal to the base schema in that it does not need to know about the names and the granularity of the base schema patterns.)

This NVDL is an example of the “epischema” approach that I presented at XML Prague 2017:
http://archive.xmlprague.cz/2017/files/presentations/epischema/index.html#/

The epischema itself is at
https://subversion.le-tex.de/common/schema/tei-cssa/subtypes.rng
Of course it is a bit contrived, but no more so than your example ;)

I’m aware that most TEI users will only start using this approach when they can generate a complete NVDL with constraints from an ODD specification. I’m afraid that finding an adequate “grammar constraint”
vocabulary for ODD may already be difficult, let alone generating from ODD the RNG epischemas that implement these constraints.

Gerrit


On 28.05.2018 17:26, Elisa Beshero-Bondar wrote:

> Hi Sean,
> This is a job for my favorite type of schema language, Schematron, and
> it's available inside ODD, though a little tricky to write. Schematron
> allows for definitions of schema rules based on XPath relationships,
> so you basically write a test to say when your @type attribute is set
> to "A", the @subtype on the same element must be A1, A2, or A3. I'll
> post an example or two, here--it helps to see how these are defined in
> a functioning ODD, and we really need more available examples of
> Schematron use in ODDs.
>
> Cheers,
> Elisa
>
>
>
> On Mon, May 28, 2018 at 11:11 AM, Winslow, Sean Michael
> ([hidden email] <mailto:[hidden email]>)
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     All,____
>
>     __ __
>
>     If in TEI, if I have a list of @type values:____
>
>     A, B, C____
>
>     And @subtypes of those values:____
>
>     A: A1, A2, A3____
>
>     B: B4, B5____
>
>     C: C6, C7____
>
>     How do I represent the link between the @subtype and @type in the
>     ODD? There doesn’t seem to be an example in the documentation that I
>     can find.____
>
>     __ __
>
>     <valListtype="closed">
>     <valItemident="A">
>     <desc>A has three subtypes, A1, A2, A3</desc>
>     </valItem>
>     <valItemident="B">
>     <desc>A has two subtypes, B4, B5</desc>
>     </valItem>
>     <valItemident="C">
>     <desc>A has two subtypes, C6, C7</desc>
>     </valItem>____
>
>     </valList>____
>
>     __ __
>
>     I wpould think I would nest a valList inside the relevant valItem,
>     but this does not seem to be allowed by valItem. ____
>
>     __ __
>
>     <valListtype="closed">
>     <valItemident="A">
>     <desc>A has three subtypes, A1, A2, A3</desc>____
>
>     <attDefident="subtype"mode="replace">____
>
>     <valListtype="closed">
>     <valItemident="A1">
>     </valItem>
>     <valItemident="A2">
>     </valItem>
>     <valItemident="A3">
>     </valItem>____
>
>     </valList>____
>
>     </attDef>
>     </valItem>____
>
>     __ __
>
>     Gives : element "attDef" not allowed here; expected the element
>     end-tag or element "altIdent", "desc", "equiv", "gloss", "paramList"
>     or "remarks"____
>
>     __ __
>
>     What is the intended way to define @subtype lists?____
>
>     __ __
>
>     Many Thanks,____
>
>     __ __
>
>     -Sean____
>
>     __ __
>
>     __ __
>
>     Dr Sean M Winslow
>     Zentrum für Informationsmodellierung
>     Austrian Centre for Digital Humanities
>     Karl-Franzens-Universität Graz
>     A-8010 Graz | Elisabethstraße 59
>    
> <https://maps.google.com/?q=Elisabethstra%C3%9Fe+59&entry=gmail&source
> =g>/III
>
>     Tel: +43 316 380 5772
>     eMail: [hidden email] <mailto:[hidden email]>
>     Web: informationsmodellierung.uni-graz.at
>     <http://informationsmodellierung.uni-graz.at>____
>
>     __ __
>
>
>
>
> --
> Elisa Beshero-Bondar, PhD
> Director, Center for the Digital Text | Associate Professor of English
> University of Pittsburgh at Greensburg | Humanities Division
> 150 Finoli Drive
> Greensburg, PA  15601  USA
> E-mail: [hidden email] <mailto:[hidden email]> Development site:
> http://newtfire.org <http://newtfire.org/>

--
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany Phone +49 341 355356 110, Fax +49 341 355356 510 [hidden email], http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig Registernummer / Registration Number: HRB 24930

Geschäftsführer / Managing Directors:
Gerrit Imsieke, Svea Jelonek, Thomas Schmidt
Reply | Threaded
Open this post in threaded view
|

Re: AW: subtypes of types

Imsieke, Gerrit, le-tex
Hi Sean,

I agree if the presupposition is to maintain an ODD in the first place.

However, there are people (like us, many of our customers, or DFG [1])
who want to have some baseline compliance with a widespread TEI
customization and then add their constraints. These people sometimes
don’t deal with ODD at all, and I think it isn’t yet illegal to do so.

On the other hand, it is desirable to express co-occurrence constraints
in ODD, too. This is what I was trying to say in the last paragraph of
the previous message. Once there are means for expressing these
constraints in ODD, users should be able to have an option to generate
either
– Embedded Schematron rules,
– an External Schematron file,
– both Schematron variants, but with Schematron Quick Fixes, or
– a base schema with Epischemas, wrapped in NVDL
– a imported RNG schema with overrides to accommodate the constraints
(this may become messy though – as Eric van der Vlist wrote, restricting
grammar-like schemas is not easy if they lack the granularity [2]).

As I said, the epischema approach has the advantage of allowing content
completion out of the box, which is quite useful in many situations.

Users who rely on ODD to maintain their customizations need to wait
until someone proposes amendments for expressing co-occurrence
constraints in ODD and until someone adapts the schema-generating XSLT
in order to support epischemas.

Gerrit

[1]
http://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/foerderkriterien_editionen_literaturwissenschaft.pdf
[2]
http://books.xmlschemata.org/relaxng/relax-CHP-12-SECT-1.html#relax-CHP-12-SECT-1.3

On 29.05.2018 11:11, Winslow, Sean Michael ([hidden email]) wrote:

> Gerrit,
>
> Adding the constraints in Relax NG seems to defeat the purpose of making an ODD, doesn't it? Suddenly, one document does not do it all, and two documents are needed, one to describe the document as TEI and document it, and one to add the constraints to an already-transformed version of the first. It also risks someone getting their hands on and transforming the ODD without the constraints.
>
> Best,
>
> -Sean
>
> Dr Sean M Winslow
> Zentrum für Informationsmodellierung
> eMail: [hidden email]
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: TEI (Text Encoding Initiative) public discussion list <[hidden email]> Im Auftrag von Imsieke, Gerrit, le-tex
> Gesendet: Dienstag, 29. Mai 2018 01:19
> An: [hidden email]
> Betreff: Re: subtypes of types
>
> Hi Elisa and Sean,
>
> Co-occurrence constraints are in fact a job for MY favorite schema language, and that is Relax NG.
>
> ODD does not (yet) provide native co-occurrence constraints (apart from embedded Schematron), and this is where I, as a TEI outsider and as a native Relax NG speaker, recommend filtering a base TEI schema by another Relax NG schema that permits everything except the type/subtype constraints.
>
> A benefit of this approach is: In contrast to Schematron (that only checks validity retroactively), it gives you excellent content completion in oXygen (versions 19.0 or newer).
>
> This is the NVDL that implements your constraint on top of a TEI allPlus base schema:
> https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_subtypes.nvdl
> If you are using oXygen, you can prepend the following xml-model PI to your document:
> <?xml-model
> href="https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_subtypes.nvdl"
>
>      type="application/xml"
> schematypens="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0"?>
>
> You see in the NVDL that you can refer to any base schema, and this is another nice property of this approach: It is orthogonal, it does not depend on knowledge of the inner building blocks (named patterns) of your base schema. (Schematron, of course, is also orthogonal to the base schema in that it does not need to know about the names and the granularity of the base schema patterns.)
>
> This NVDL is an example of the “epischema” approach that I presented at XML Prague 2017:
> http://archive.xmlprague.cz/2017/files/presentations/epischema/index.html#/
>
> The epischema itself is at
> https://subversion.le-tex.de/common/schema/tei-cssa/subtypes.rng
> Of course it is a bit contrived, but no more so than your example ;)
>
> I’m aware that most TEI users will only start using this approach when they can generate a complete NVDL with constraints from an ODD specification. I’m afraid that finding an adequate “grammar constraint”
> vocabulary for ODD may already be difficult, let alone generating from ODD the RNG epischemas that implement these constraints.
>
> Gerrit
>
>
> On 28.05.2018 17:26, Elisa Beshero-Bondar wrote:
>> Hi Sean,
>> This is a job for my favorite type of schema language, Schematron, and
>> it's available inside ODD, though a little tricky to write. Schematron
>> allows for definitions of schema rules based on XPath relationships,
>> so you basically write a test to say when your @type attribute is set
>> to "A", the @subtype on the same element must be A1, A2, or A3. I'll
>> post an example or two, here--it helps to see how these are defined in
>> a functioning ODD, and we really need more available examples of
>> Schematron use in ODDs.
>>
>> Cheers,
>> Elisa
>>
>>
>>
>> On Mon, May 28, 2018 at 11:11 AM, Winslow, Sean Michael
>> ([hidden email] <mailto:[hidden email]>)
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>      All,____
>>
>>      __ __
>>
>>      If in TEI, if I have a list of @type values:____
>>
>>      A, B, C____
>>
>>      And @subtypes of those values:____
>>
>>      A: A1, A2, A3____
>>
>>      B: B4, B5____
>>
>>      C: C6, C7____
>>
>>      How do I represent the link between the @subtype and @type in the
>>      ODD? There doesn’t seem to be an example in the documentation that I
>>      can find.____
>>
>>      __ __
>>
>>      <valListtype="closed">
>>      <valItemident="A">
>>      <desc>A has three subtypes, A1, A2, A3</desc>
>>      </valItem>
>>      <valItemident="B">
>>      <desc>A has two subtypes, B4, B5</desc>
>>      </valItem>
>>      <valItemident="C">
>>      <desc>A has two subtypes, C6, C7</desc>
>>      </valItem>____
>>
>>      </valList>____
>>
>>      __ __
>>
>>      I wpould think I would nest a valList inside the relevant valItem,
>>      but this does not seem to be allowed by valItem. ____
>>
>>      __ __
>>
>>      <valListtype="closed">
>>      <valItemident="A">
>>      <desc>A has three subtypes, A1, A2, A3</desc>____
>>
>>      <attDefident="subtype"mode="replace">____
>>
>>      <valListtype="closed">
>>      <valItemident="A1">
>>      </valItem>
>>      <valItemident="A2">
>>      </valItem>
>>      <valItemident="A3">
>>      </valItem>____
>>
>>      </valList>____
>>
>>      </attDef>
>>      </valItem>____
>>
>>      __ __
>>
>>      Gives : element "attDef" not allowed here; expected the element
>>      end-tag or element "altIdent", "desc", "equiv", "gloss", "paramList"
>>      or "remarks"____
>>
>>      __ __
>>
>>      What is the intended way to define @subtype lists?____
>>
>>      __ __
>>
>>      Many Thanks,____
>>
>>      __ __
>>
>>      -Sean____
>>
>>      __ __
>>
>>      __ __
>>
>>      Dr Sean M Winslow
>>      Zentrum für Informationsmodellierung
>>      Austrian Centre for Digital Humanities
>>      Karl-Franzens-Universität Graz
>>      A-8010 Graz | Elisabethstraße 59
>>      
>> <https://maps.google.com/?q=Elisabethstra%C3%9Fe+59&entry=gmail&source
>> =g>/III
>>
>>      Tel: +43 316 380 5772
>>      eMail: [hidden email] <mailto:[hidden email]>
>>      Web: informationsmodellierung.uni-graz.at
>>      <http://informationsmodellierung.uni-graz.at>____
>>
>>      __ __
>>
>>
>>
>>
>> --
>> Elisa Beshero-Bondar, PhD
>> Director, Center for the Digital Text | Associate Professor of English
>> University of Pittsburgh at Greensburg | Humanities Division
>> 150 Finoli Drive
>> Greensburg, PA  15601  USA
>> E-mail: [hidden email] <mailto:[hidden email]> Development site:
>> http://newtfire.org <http://newtfire.org/>
>
> --
> Gerrit Imsieke
> Geschäftsführer / Managing Director
> le-tex publishing services GmbH
> Weissenfelser Str. 84, 04229 Leipzig, Germany Phone +49 341 355356 110, Fax +49 341 355356 510 [hidden email], http://www.le-tex.de
>
> Registergericht / Commercial Register: Amtsgericht Leipzig Registernummer / Registration Number: HRB 24930
>
> Geschäftsführer / Managing Directors:
> Gerrit Imsieke, Svea Jelonek, Thomas Schmidt
>

--
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
[hidden email], http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

Geschäftsführer / Managing Directors:
Gerrit Imsieke, Svea Jelonek, Thomas Schmidt
Reply | Threaded
Open this post in threaded view
|

Re: AW: subtypes of types

Elisa Beshero-Bondar
Gerrit-- I'm eager to experiment with Epischemas, and I agree that it would be great to see these implemented in ODDs, since content completion is certainly helpful. One of my projects includes a giant file or prosopography lists containing hundreds of xml:ids, and my Schematron solutions, while quick for me to implement, don't necessarily help contributors to the project to select the right ids for the right elements. 

One thing I need to implement in my ODD for this giant project is a good mechanism for updating the ODD with new ids as they're added (so I don't have to do this myself). XSLT can do the job, but so can Schematron--though without anything like content completion. I wonder if the NVDL might be a good solution to sit alongside the ODD? I'm curious to learn more about this as I'm still trying to find the right solution for this big project! 

Cheers,
Elisa

On Tue, May 29, 2018 at 5:45 AM, Imsieke, Gerrit, le-tex <[hidden email]> wrote:
Hi Sean,

I agree if the presupposition is to maintain an ODD in the first place.

However, there are people (like us, many of our customers, or DFG [1]) who want to have some baseline compliance with a widespread TEI customization and then add their constraints. These people sometimes don’t deal with ODD at all, and I think it isn’t yet illegal to do so.

On the other hand, it is desirable to express co-occurrence constraints in ODD, too. This is what I was trying to say in the last paragraph of the previous message. Once there are means for expressing these constraints in ODD, users should be able to have an option to generate either
– Embedded Schematron rules,
– an External Schematron file,
– both Schematron variants, but with Schematron Quick Fixes, or
– a base schema with Epischemas, wrapped in NVDL
– a imported RNG schema with overrides to accommodate the constraints (this may become messy though – as Eric van der Vlist wrote, restricting grammar-like schemas is not easy if they lack the granularity [2]).

As I said, the epischema approach has the advantage of allowing content completion out of the box, which is quite useful in many situations.

Users who rely on ODD to maintain their customizations need to wait until someone proposes amendments for expressing co-occurrence constraints in ODD and until someone adapts the schema-generating XSLT in order to support epischemas.

Gerrit

[1] http://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/foerderkriterien_editionen_literaturwissenschaft.pdf
[2] http://books.xmlschemata.org/relaxng/relax-CHP-12-SECT-1.html#relax-CHP-12-SECT-1.3


On 29.05.2018 11:11, Winslow, Sean Michael ([hidden email]) wrote:
Gerrit,

Adding the constraints in Relax NG seems to defeat the purpose of making an ODD, doesn't it? Suddenly, one document does not do it all, and two documents are needed, one to describe the document as TEI and document it, and one to add the constraints to an already-transformed version of the first. It also risks someone getting their hands on and transforming the ODD without the constraints.

Best,

-Sean

Dr Sean M Winslow
Zentrum für Informationsmodellierung
eMail: [hidden email]



-----Ursprüngliche Nachricht-----
Von: TEI (Text Encoding Initiative) public discussion list <[hidden email]> Im Auftrag von Imsieke, Gerrit, le-tex
Gesendet: Dienstag, 29. Mai 2018 01:19
An: [hidden email]
Betreff: Re: subtypes of types

Hi Elisa and Sean,

Co-occurrence constraints are in fact a job for MY favorite schema language, and that is Relax NG.

ODD does not (yet) provide native co-occurrence constraints (apart from embedded Schematron), and this is where I, as a TEI outsider and as a native Relax NG speaker, recommend filtering a base TEI schema by another Relax NG schema that permits everything except the type/subtype constraints.

A benefit of this approach is: In contrast to Schematron (that only checks validity retroactively), it gives you excellent content completion in oXygen (versions 19.0 or newer).

This is the NVDL that implements your constraint on top of a TEI allPlus base schema:
https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_subtypes.nvdl
If you are using oXygen, you can prepend the following xml-model PI to your document:
<?xml-model
href="https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_subtypes.nvdl"

     type="application/xml"
schematypens="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0"?>

You see in the NVDL that you can refer to any base schema, and this is another nice property of this approach: It is orthogonal, it does not depend on knowledge of the inner building blocks (named patterns) of your base schema. (Schematron, of course, is also orthogonal to the base schema in that it does not need to know about the names and the granularity of the base schema patterns.)

This NVDL is an example of the “epischema” approach that I presented at XML Prague 2017:
http://archive.xmlprague.cz/2017/files/presentations/epischema/index.html#/

The epischema itself is at
https://subversion.le-tex.de/common/schema/tei-cssa/subtypes.rng
Of course it is a bit contrived, but no more so than your example ;)

I’m aware that most TEI users will only start using this approach when they can generate a complete NVDL with constraints from an ODD specification. I’m afraid that finding an adequate “grammar constraint”
vocabulary for ODD may already be difficult, let alone generating from ODD the RNG epischemas that implement these constraints.

Gerrit


On 28.05.2018 17:26, Elisa Beshero-Bondar wrote:
Hi Sean,
This is a job for my favorite type of schema language, Schematron, and
it's available inside ODD, though a little tricky to write. Schematron
allows for definitions of schema rules based on XPath relationships,
so you basically write a test to say when your @type attribute is set
to "A", the @subtype on the same element must be A1, A2, or A3. I'll
post an example or two, here--it helps to see how these are defined in
a functioning ODD, and we really need more available examples of
Schematron use in ODDs.

Cheers,
Elisa



On Mon, May 28, 2018 at 11:11 AM, Winslow, Sean Michael
([hidden email] <mailto:[hidden email]>)
<[hidden email] <mailto:[hidden email]>> wrote:

     All,____

     __ __

     If in TEI, if I have a list of @type values:____

     A, B, C____

     And @subtypes of those values:____

     A: A1, A2, A3____

     B: B4, B5____

     C: C6, C7____

     How do I represent the link between the @subtype and @type in the
     ODD? There doesn’t seem to be an example in the documentation that I
     can find.____

     __ __

     <valListtype="closed">
     <valItemident="A">
     <desc>A has three subtypes, A1, A2, A3</desc>
     </valItem>
     <valItemident="B">
     <desc>A has two subtypes, B4, B5</desc>
     </valItem>
     <valItemident="C">
     <desc>A has two subtypes, C6, C7</desc>
     </valItem>____

     </valList>____

     __ __

     I wpould think I would nest a valList inside the relevant valItem,
     but this does not seem to be allowed by valItem. ____

     __ __

     <valListtype="closed">
     <valItemident="A">
     <desc>A has three subtypes, A1, A2, A3</desc>____

     <attDefident="subtype"mode="replace">____

     <valListtype="closed">
     <valItemident="A1">
     </valItem>
     <valItemident="A2">
     </valItem>
     <valItemident="A3">
     </valItem>____

     </valList>____

     </attDef>
     </valItem>____

     __ __

     Gives : element "attDef" not allowed here; expected the element
     end-tag or element "altIdent", "desc", "equiv", "gloss", "paramList"
     or "remarks"____

     __ __

     What is the intended way to define @subtype lists?____

     __ __

     Many Thanks,____

     __ __

     -Sean____

     __ __

     __ __

     Dr Sean M Winslow
     Zentrum für Informationsmodellierung
     Austrian Centre for Digital Humanities
     Karl-Franzens-Universität Graz
     A-8010 Graz | Elisabethstraße 59
     <https://maps.google.com/?q=Elisabethstra%C3%9Fe+59&entry=gmail&source
=g>/III

     Tel: +43 316 380 5772
     eMail: [hidden email] <mailto:[hidden email]>
     Web: informationsmodellierung.uni-graz.at
     <http://informationsmodellierung.uni-graz.at>____

     __ __




--
Elisa Beshero-Bondar, PhD
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA  15601  USA
E-mail: [hidden email] <mailto:[hidden email]> Development site:
http://newtfire.org <http://newtfire.org/>

--
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany Phone +49 341 355356 110, Fax +49 341 355356 510 [hidden email], http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig Registernummer / Registration Number: HRB 24930

Geschäftsführer / Managing Directors:
Gerrit Imsieke, Svea Jelonek, Thomas Schmidt


--
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
[hidden email], http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

Geschäftsführer / Managing Directors:
Gerrit Imsieke, Svea Jelonek, Thomas Schmidt



--
Elisa Beshero-Bondar, PhD
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA  15601  USA
E-mail:[hidden email]
Development site: http://newtfire.org
Reply | Threaded
Open this post in threaded view
|

Re: AW: subtypes of types

Elisa Beshero-Bondar
PS: By which I mean, the trouble with Schematron when you are coordinating lots of complex combinations is, people can't easily see what the right options are for them to choose. Schematron does a check and tells them when they're wrong.  Probably Schematron is best for proof-checking things like whether birth and death dates are properly sequenced. 

Working Schematron into ODD is more cumbersome than running it as its own separate file, just due to the sheer proliferation of namespaces in the file--it's a little bewildering to keep up with without a better schema on the ODD itself! I sometimes think maybe we ought to reconsider that ODDs need not be the only schema in effect, but might themselves document additional schema files that are designed to validate in tandem.

Best,
Elisa

On Tue, May 29, 2018 at 7:56 AM, Elisa Beshero-Bondar <[hidden email]> wrote:
Gerrit-- I'm eager to experiment with Epischemas, and I agree that it would be great to see these implemented in ODDs, since content completion is certainly helpful. One of my projects includes a giant file or prosopography lists containing hundreds of xml:ids, and my Schematron solutions, while quick for me to implement, don't necessarily help contributors to the project to select the right ids for the right elements. 

One thing I need to implement in my ODD for this giant project is a good mechanism for updating the ODD with new ids as they're added (so I don't have to do this myself). XSLT can do the job, but so can Schematron--though without anything like content completion. I wonder if the NVDL might be a good solution to sit alongside the ODD? I'm curious to learn more about this as I'm still trying to find the right solution for this big project! 

Cheers,
Elisa

On Tue, May 29, 2018 at 5:45 AM, Imsieke, Gerrit, le-tex <[hidden email]> wrote:
Hi Sean,

I agree if the presupposition is to maintain an ODD in the first place.

However, there are people (like us, many of our customers, or DFG [1]) who want to have some baseline compliance with a widespread TEI customization and then add their constraints. These people sometimes don’t deal with ODD at all, and I think it isn’t yet illegal to do so.

On the other hand, it is desirable to express co-occurrence constraints in ODD, too. This is what I was trying to say in the last paragraph of the previous message. Once there are means for expressing these constraints in ODD, users should be able to have an option to generate either
– Embedded Schematron rules,
– an External Schematron file,
– both Schematron variants, but with Schematron Quick Fixes, or
– a base schema with Epischemas, wrapped in NVDL
– a imported RNG schema with overrides to accommodate the constraints (this may become messy though – as Eric van der Vlist wrote, restricting grammar-like schemas is not easy if they lack the granularity [2]).

As I said, the epischema approach has the advantage of allowing content completion out of the box, which is quite useful in many situations.

Users who rely on ODD to maintain their customizations need to wait until someone proposes amendments for expressing co-occurrence constraints in ODD and until someone adapts the schema-generating XSLT in order to support epischemas.

Gerrit

[1] http://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/foerderkriterien_editionen_literaturwissenschaft.pdf
[2] http://books.xmlschemata.org/relaxng/relax-CHP-12-SECT-1.html#relax-CHP-12-SECT-1.3


On 29.05.2018 11:11, Winslow, Sean Michael ([hidden email]) wrote:
Gerrit,

Adding the constraints in Relax NG seems to defeat the purpose of making an ODD, doesn't it? Suddenly, one document does not do it all, and two documents are needed, one to describe the document as TEI and document it, and one to add the constraints to an already-transformed version of the first. It also risks someone getting their hands on and transforming the ODD without the constraints.

Best,

-Sean

Dr Sean M Winslow
Zentrum für Informationsmodellierung
eMail: [hidden email]



-----Ursprüngliche Nachricht-----
Von: TEI (Text Encoding Initiative) public discussion list <[hidden email]> Im Auftrag von Imsieke, Gerrit, le-tex
Gesendet: Dienstag, 29. Mai 2018 01:19
An: [hidden email]
Betreff: Re: subtypes of types

Hi Elisa and Sean,

Co-occurrence constraints are in fact a job for MY favorite schema language, and that is Relax NG.

ODD does not (yet) provide native co-occurrence constraints (apart from embedded Schematron), and this is where I, as a TEI outsider and as a native Relax NG speaker, recommend filtering a base TEI schema by another Relax NG schema that permits everything except the type/subtype constraints.

A benefit of this approach is: In contrast to Schematron (that only checks validity retroactively), it gives you excellent content completion in oXygen (versions 19.0 or newer).

This is the NVDL that implements your constraint on top of a TEI allPlus base schema:
https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_subtypes.nvdl
If you are using oXygen, you can prepend the following xml-model PI to your document:
<?xml-model
href="https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_subtypes.nvdl"

     type="application/xml"
schematypens="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0"?>

You see in the NVDL that you can refer to any base schema, and this is another nice property of this approach: It is orthogonal, it does not depend on knowledge of the inner building blocks (named patterns) of your base schema. (Schematron, of course, is also orthogonal to the base schema in that it does not need to know about the names and the granularity of the base schema patterns.)

This NVDL is an example of the “epischema” approach that I presented at XML Prague 2017:
http://archive.xmlprague.cz/2017/files/presentations/epischema/index.html#/

The epischema itself is at
https://subversion.le-tex.de/common/schema/tei-cssa/subtypes.rng
Of course it is a bit contrived, but no more so than your example ;)

I’m aware that most TEI users will only start using this approach when they can generate a complete NVDL with constraints from an ODD specification. I’m afraid that finding an adequate “grammar constraint”
vocabulary for ODD may already be difficult, let alone generating from ODD the RNG epischemas that implement these constraints.

Gerrit


On 28.05.2018 17:26, Elisa Beshero-Bondar wrote:
Hi Sean,
This is a job for my favorite type of schema language, Schematron, and
it's available inside ODD, though a little tricky to write. Schematron
allows for definitions of schema rules based on XPath relationships,
so you basically write a test to say when your @type attribute is set
to "A", the @subtype on the same element must be A1, A2, or A3. I'll
post an example or two, here--it helps to see how these are defined in
a functioning ODD, and we really need more available examples of
Schematron use in ODDs.

Cheers,
Elisa



On Mon, May 28, 2018 at 11:11 AM, Winslow, Sean Michael
([hidden email] <mailto:[hidden email]>)
<[hidden email] <mailto:[hidden email]>> wrote:

     All,____

     __ __

     If in TEI, if I have a list of @type values:____

     A, B, C____

     And @subtypes of those values:____

     A: A1, A2, A3____

     B: B4, B5____

     C: C6, C7____

     How do I represent the link between the @subtype and @type in the
     ODD? There doesn’t seem to be an example in the documentation that I
     can find.____

     __ __

     <valListtype="closed">
     <valItemident="A">
     <desc>A has three subtypes, A1, A2, A3</desc>
     </valItem>
     <valItemident="B">
     <desc>A has two subtypes, B4, B5</desc>
     </valItem>
     <valItemident="C">
     <desc>A has two subtypes, C6, C7</desc>
     </valItem>____

     </valList>____

     __ __

     I wpould think I would nest a valList inside the relevant valItem,
     but this does not seem to be allowed by valItem. ____

     __ __

     <valListtype="closed">
     <valItemident="A">
     <desc>A has three subtypes, A1, A2, A3</desc>____

     <attDefident="subtype"mode="replace">____

     <valListtype="closed">
     <valItemident="A1">
     </valItem>
     <valItemident="A2">
     </valItem>
     <valItemident="A3">
     </valItem>____

     </valList>____

     </attDef>
     </valItem>____

     __ __

     Gives : element "attDef" not allowed here; expected the element
     end-tag or element "altIdent", "desc", "equiv", "gloss", "paramList"
     or "remarks"____

     __ __

     What is the intended way to define @subtype lists?____

     __ __

     Many Thanks,____

     __ __

     -Sean____

     __ __

     __ __

     Dr Sean M Winslow
     Zentrum für Informationsmodellierung
     Austrian Centre for Digital Humanities
     Karl-Franzens-Universität Graz
     A-8010 Graz | Elisabethstraße 59
     <https://maps.google.com/?q=Elisabethstra%C3%9Fe+59&entry=gmail&source
=g>/III

     Tel: +43 316 380 5772
     eMail: [hidden email] <mailto:[hidden email]>
     Web: informationsmodellierung.uni-graz.at
     <http://informationsmodellierung.uni-graz.at>____

     __ __




--
Elisa Beshero-Bondar, PhD
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA  15601  USA
E-mail: [hidden email] <mailto:[hidden email]> Development site:
http://newtfire.org <http://newtfire.org/>

--
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany Phone +49 341 355356 110, Fax +49 341 355356 510 [hidden email], http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig Registernummer / Registration Number: HRB 24930

Geschäftsführer / Managing Directors:
Gerrit Imsieke, Svea Jelonek, Thomas Schmidt


--
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
[hidden email], http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

Geschäftsführer / Managing Directors:
Gerrit Imsieke, Svea Jelonek, Thomas Schmidt



--
Elisa Beshero-Bondar, PhD
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA  15601  USA
E-mail:[hidden email]
Development site: http://newtfire.org



--
Elisa Beshero-Bondar, PhD
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA  15601  USA
E-mail:[hidden email]
Development site: http://newtfire.org
Reply | Threaded
Open this post in threaded view
|

Re: subtypes of types

Gioele Barabucci-2
In reply to this post by Imsieke, Gerrit, le-tex
Hello,

Am 29.05.2018 um 11:45 schrieb Imsieke, Gerrit, le-tex:
> However, there are people (like us, many of our customers, or DFG [1])
> who want to have some baseline compliance with a widespread TEI
> customization and then add their constraints. These people sometimes
> don’t deal with ODD at all, and I think it isn’t yet illegal to do so.

To add to this point, i really would like to express my desire for a
reduced ODDv2 that focuses on:

1. Select a subset of TEI elements and document it with project-specific
notes.

2. Add additional constraints (be them "can appear only in" or "this is
list of accepted values")

3. Select which existing constraints should be enforced (I'm a sinner)

5. Allows other (sub)projects to restart from point 1 using this newly
created subschema as the base schema.

This ODDv2 would pragmatically limit itself to Relax NG+Schematron+NVDL
and produce a set of epischemas (or something equivalent) and the
documentation of the schema at the same time.

Currently ODD does not "does it all" for us. Creating the documentation
is possible, but making it actually usable and readable (see [1])
requires a lot of pruning, hacks and "going against the grain". At the
same time ODD is not able to express the co-constraints that are being
discussed in this thread and that are really useful when it comes to
helping the editors with features like autocompletion.

We use ODD because this is the tool of the trade in this moment, but it
looks like many are starting to ask for a better tool.

Regards,

[1] https://thomas-institut.github.io/averroes-tei/averroes-guidelines.html

--
Gioele Barabucci <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: AW: subtypes of types

Martin Holmes
In reply to this post by Elisa Beshero-Bondar
Hi Elisa,

Most of my projects now have an ODD build process which uses XSLT to
harvest (say) all the xml:ids of <person> elements in the project and
uses them to populate the valList items of persName/@ref, before
rebuilding the schema. That means that as long as the schema gets
regenerated regularly, you get automatic content completion and sound
constraints, and all the user has to do is to add a new <person> and
then regenerate the schema to make their new person available. This is
an example of an ant build file that does this:

<https://revision.hcmc.uvic.ca/svn/london/db/data/utilities/buildODD.xml>

and this is an XSLT file that processes the ODD to incorporate various
taxonomies from the dataset:

<https://revision.hcmc.uvic.ca/svn/london/db/data/utilities/taxonomies_to_odd_fragments.xsl>

Cheers,
Martin



On 2018-05-29 04:56 AM, Elisa Beshero-Bondar wrote:

> Gerrit-- I'm eager to experiment with Epischemas, and I agree that it
> would be great to see these implemented in ODDs, since content
> completion is certainly helpful. One of my projects includes a giant
> file or prosopography lists containing hundreds of xml:ids, and my
> Schematron solutions, while quick for me to implement, don't necessarily
> help contributors to the project to select the right ids for the right
> elements.
>
> One thing I need to implement in my ODD for this giant project is a good
> mechanism for updating the ODD with new ids as they're added (so I don't
> have to do this myself). XSLT can do the job, but so can
> Schematron--though without anything like content completion. I wonder if
> the NVDL might be a good solution to sit alongside the ODD? I'm curious
> to learn more about this as I'm still trying to find the right solution
> for this big project!
>
> Cheers,
> Elisa
>
> On Tue, May 29, 2018 at 5:45 AM, Imsieke, Gerrit, le-tex
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hi Sean,
>
>     I agree if the presupposition is to maintain an ODD in the first place.
>
>     However, there are people (like us, many of our customers, or DFG
>     [1]) who want to have some baseline compliance with a widespread TEI
>     customization and then add their constraints. These people sometimes
>     don’t deal with ODD at all, and I think it isn’t yet illegal to do so.
>
>     On the other hand, it is desirable to express co-occurrence
>     constraints in ODD, too. This is what I was trying to say in the
>     last paragraph of the previous message. Once there are means for
>     expressing these constraints in ODD, users should be able to have an
>     option to generate either
>     – Embedded Schematron rules,
>     – an External Schematron file,
>     – both Schematron variants, but with Schematron Quick Fixes, or
>     – a base schema with Epischemas, wrapped in NVDL
>     – a imported RNG schema with overrides to accommodate the
>     constraints (this may become messy though – as Eric van der Vlist
>     wrote, restricting grammar-like schemas is not easy if they lack the
>     granularity [2]).
>
>     As I said, the epischema approach has the advantage of allowing
>     content completion out of the box, which is quite useful in many
>     situations.
>
>     Users who rely on ODD to maintain their customizations need to wait
>     until someone proposes amendments for expressing co-occurrence
>     constraints in ODD and until someone adapts the schema-generating
>     XSLT in order to support epischemas.
>
>     Gerrit
>
>     [1]
>     http://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/foerderkriterien_editionen_literaturwissenschaft.pdf
>     <http://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/foerderkriterien_editionen_literaturwissenschaft.pdf>
>     [2]
>     http://books.xmlschemata.org/relaxng/relax-CHP-12-SECT-1.html#relax-CHP-12-SECT-1.3
>     <http://books.xmlschemata.org/relaxng/relax-CHP-12-SECT-1.html#relax-CHP-12-SECT-1.3>
>
>
>     On 29.05.2018 11:11, Winslow, Sean Michael ([hidden email]
>     <mailto:[hidden email]>) wrote:
>
>         Gerrit,
>
>         Adding the constraints in Relax NG seems to defeat the purpose
>         of making an ODD, doesn't it? Suddenly, one document does not do
>         it all, and two documents are needed, one to describe the
>         document as TEI and document it, and one to add the constraints
>         to an already-transformed version of the first. It also risks
>         someone getting their hands on and transforming the ODD without
>         the constraints.
>
>         Best,
>
>         -Sean
>
>         Dr Sean M Winslow
>         Zentrum für Informationsmodellierung
>         eMail: [hidden email] <mailto:[hidden email]>
>
>
>
>         -----Ursprüngliche Nachricht-----
>         Von: TEI (Text Encoding Initiative) public discussion list
>         <[hidden email] <mailto:[hidden email]>> Im
>         Auftrag von Imsieke, Gerrit, le-tex
>         Gesendet: Dienstag, 29. Mai 2018 01:19
>         An: [hidden email] <mailto:[hidden email]>
>         Betreff: Re: subtypes of types
>
>         Hi Elisa and Sean,
>
>         Co-occurrence constraints are in fact a job for MY favorite
>         schema language, and that is Relax NG.
>
>         ODD does not (yet) provide native co-occurrence constraints
>         (apart from embedded Schematron), and this is where I, as a TEI
>         outsider and as a native Relax NG speaker, recommend filtering a
>         base TEI schema by another Relax NG schema that permits
>         everything except the type/subtype constraints.
>
>         A benefit of this approach is: In contrast to Schematron (that
>         only checks validity retroactively), it gives you excellent
>         content completion in oXygen (versions 19.0 or newer).
>
>         This is the NVDL that implements your constraint on top of a TEI
>         allPlus base schema:
>         https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_subtypes.nvdl
>         <https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_subtypes.nvdl>
>         If you are using oXygen, you can prepend the following xml-model
>         PI to your document:
>         <?xml-model
>         href="https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_subtypes.nvdl
>         <https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_subtypes.nvdl>"
>
>               type="application/xml"
>         schematypens="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0
>         <http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0>"?>
>
>         You see in the NVDL that you can refer to any base schema, and
>         this is another nice property of this approach: It is
>         orthogonal, it does not depend on knowledge of the inner
>         building blocks (named patterns) of your base schema.
>         (Schematron, of course, is also orthogonal to the base schema in
>         that it does not need to know about the names and the
>         granularity of the base schema patterns.)
>
>         This NVDL is an example of the “epischema” approach that I
>         presented at XML Prague 2017:
>         http://archive.xmlprague.cz/2017/files/presentations/epischema/index.html#/
>         <http://archive.xmlprague.cz/2017/files/presentations/epischema/index.html#/>
>
>         The epischema itself is at
>         https://subversion.le-tex.de/common/schema/tei-cssa/subtypes.rng
>         <https://subversion.le-tex.de/common/schema/tei-cssa/subtypes.rng>
>         Of course it is a bit contrived, but no more so than your example ;)
>
>         I’m aware that most TEI users will only start using this
>         approach when they can generate a complete NVDL with constraints
>         from an ODD specification. I’m afraid that finding an adequate
>         “grammar constraint”
>         vocabulary for ODD may already be difficult, let alone
>         generating from ODD the RNG epischemas that implement these
>         constraints.
>
>         Gerrit
>
>
>         On 28.05.2018 17:26, Elisa Beshero-Bondar wrote:
>
>             Hi Sean,
>             This is a job for my favorite type of schema language,
>             Schematron, and
>             it's available inside ODD, though a little tricky to write.
>             Schematron
>             allows for definitions of schema rules based on XPath
>             relationships,
>             so you basically write a test to say when your @type
>             attribute is set
>             to "A", the @subtype on the same element must be A1, A2, or
>             A3. I'll
>             post an example or two, here--it helps to see how these are
>             defined in
>             a functioning ODD, and we really need more available examples of
>             Schematron use in ODDs.
>
>             Cheers,
>             Elisa
>
>
>
>             On Mon, May 28, 2018 at 11:11 AM, Winslow, Sean Michael
>             ([hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email]
>             <mailto:[hidden email]>>)
>             <[hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email]
>             <mailto:[hidden email]>>> wrote:
>
>                   All,____
>
>                   __ __
>
>                   If in TEI, if I have a list of @type values:____
>
>                   A, B, C____
>
>                   And @subtypes of those values:____
>
>                   A: A1, A2, A3____
>
>                   B: B4, B5____
>
>                   C: C6, C7____
>
>                   How do I represent the link between the @subtype and
>             @type in the
>                   ODD? There doesn’t seem to be an example in the
>             documentation that I
>                   can find.____
>
>                   __ __
>
>                   <valListtype="closed">
>                   <valItemident="A">
>                   <desc>A has three subtypes, A1, A2, A3</desc>
>                   </valItem>
>                   <valItemident="B">
>                   <desc>A has two subtypes, B4, B5</desc>
>                   </valItem>
>                   <valItemident="C">
>                   <desc>A has two subtypes, C6, C7</desc>
>                   </valItem>____
>
>                   </valList>____
>
>                   __ __
>
>                   I wpould think I would nest a valList inside the
>             relevant valItem,
>                   but this does not seem to be allowed by valItem. ____
>
>                   __ __
>
>                   <valListtype="closed">
>                   <valItemident="A">
>                   <desc>A has three subtypes, A1, A2, A3</desc>____
>
>                   <attDefident="subtype"mode="replace">____
>
>                   <valListtype="closed">
>                   <valItemident="A1">
>                   </valItem>
>                   <valItemident="A2">
>                   </valItem>
>                   <valItemident="A3">
>                   </valItem>____
>
>                   </valList>____
>
>                   </attDef>
>                   </valItem>____
>
>                   __ __
>
>                   Gives : element "attDef" not allowed here; expected
>             the element
>                   end-tag or element "altIdent", "desc", "equiv",
>             "gloss", "paramList"
>                   or "remarks"____
>
>                   __ __
>
>                   What is the intended way to define @subtype lists?____
>
>                   __ __
>
>                   Many Thanks,____
>
>                   __ __
>
>                   -Sean____
>
>                   __ __
>
>                   __ __
>
>                   Dr Sean M Winslow
>                   Zentrum für Informationsmodellierung
>                   Austrian Centre for Digital Humanities
>                   Karl-Franzens-Universität Graz
>                   A-8010 Graz | Elisabethstraße 59
>                
>               <https://maps.google.com/?q=Elisabethstra%C3%9Fe+59&entry=gmail&source <https://maps.google.com/?q=Elisabethstra%C3%9Fe+59&entry=gmail&source>
>             =g>/III
>
>                   Tel: +43 316 380 5772
>                   eMail: [hidden email]
>             <mailto:[hidden email]>
>             <mailto:[hidden email]
>             <mailto:[hidden email]>>
>                   Web: informationsmodellierung.uni-graz.at
>             <http://informationsmodellierung.uni-graz.at>
>                   <http://informationsmodellierung.uni-graz.at
>             <http://informationsmodellierung.uni-graz.at>>____
>
>                   __ __
>
>
>
>
>             --
>             Elisa Beshero-Bondar, PhD
>             Director, Center for the Digital Text | Associate Professor
>             of English
>             University of Pittsburgh at Greensburg | Humanities Division
>             150 Finoli Drive
>             Greensburg, PA  15601  USA
>             E-mail: [hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>> Development site:
>             http://newtfire.org <http://newtfire.org/>
>
>
>         --
>         Gerrit Imsieke
>         Geschäftsführer / Managing Director
>         le-tex publishing services GmbH
>         Weissenfelser Str. 84, 04229 Leipzig, Germany Phone +49 341
>         355356 110, Fax +49 341 355356 510 [hidden email]
>         <mailto:[hidden email]>, http://www.le-tex.de
>
>         Registergericht / Commercial Register: Amtsgericht Leipzig
>         Registernummer / Registration Number: HRB 24930
>
>         Geschäftsführer / Managing Directors:
>         Gerrit Imsieke, Svea Jelonek, Thomas Schmidt
>
>
>     --
>     Gerrit Imsieke
>     Geschäftsführer / Managing Director
>     le-tex publishing services GmbH
>     Weissenfelser Str. 84, 04229 Leipzig, Germany
>     Phone +49 341 355356 110, Fax +49 341 355356 510
>     [hidden email] <mailto:[hidden email]>,
>     http://www.le-tex.de
>
>     Registergericht / Commercial Register: Amtsgericht Leipzig
>     Registernummer / Registration Number: HRB 24930
>
>     Geschäftsführer / Managing Directors:
>     Gerrit Imsieke, Svea Jelonek, Thomas Schmidt
>
>
>
>
> --
> Elisa Beshero-Bondar, PhD
> Director, Center for the Digital Text | Associate Professor of English
> University of Pittsburgh at Greensburg | Humanities Division
> 150 Finoli Drive
> Greensburg, PA  15601  USA
> E-mail: [hidden email] <mailto:[hidden email]>
> Development site: http://newtfire.org <http://newtfire.org/>
Reply | Threaded
Open this post in threaded view
|

Re: AW: subtypes of types

Imsieke, Gerrit, le-tex
In reply to this post by Elisa Beshero-Bondar
Hi Elisa,

Schematron’s advantage here is that it is able to check @ref attributes
dynamically across files.

I’m not fully aware whether Schematron Quick Fix is already able to look
up fix suggestions dynamically. If it is, it may be a good compromise,
almost as quick as RNG/NVDL-configured content completion yet more
flexible because of the dynamic lookup.

oXygen’s content completion can be configured to look up values
dynamically via XSLT. It is described here:
https://www.oxygenxml.com/doc/versions/20.0/ug-editor/topics/configuring-content-completion-proposals.html
The drawback of this approach is that it is bound to a specific tool and
it needs to be installed on each user’s machine (maybe as part of a
framework, which is not easy to set up either, though). However, for
mere productivity aids it might be totally acceptable to be tied to a
specific product.

If you want to configure content completion by means of epischemas/NVDL,
you can for example maintain an epischema for the person IDs that you
need to fill/update via XSLT by looking up all the person IDs. I
implemented it in an NVDL that you can associate with a document by
prepending the following PI:
<?xml-model
href="https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_person_IDs.nvdl"
type="application/xml"
schematypens="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0"?>
It contains completion suggestions, taken from
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ND.html#index-egXML-d53e108211,
for @ref in <name type="person" ref="…"> contexts.
Don’t ask me why they didn’t use <persName> in this example, because
then ODD would be sufficient, as Martin wrote. Maybe <persName> was
created because of the lacking support of co-occurrence constraints in ODD…

(The @ref attribute will still allow any URIs that are not in the list
because a <name type="person" ref="…"> with such a @ref will still be
valid according to the 'almost-anything' pattern in
https://subversion.le-tex.de/common/schema/tei-cssa/person-IDs.rng, even
when it is invalid according to the 'person-ref' pattern. You can
increase the strictness of the checks by excluding <name> from the
'almost-anything' pattern and by providing a more detailed model for
<name>, its @types and the list of @refs that they may refer to.)

The difference between this approach and what you can currently in ODD
is that in ODD, as far as I know, you can only restrict @ref to a fixed
set of values. That is, you cannot provide distinct completion
suggestions for persons, places, etc., according to the element name or
the @type value.

Although this completion mechanism may not use dynamic lookup, it is
still acceptable to run a trigger that rebuilds the epischema whenever
someone updates the underlying prosopography list.

A final note on an alternative implementation, using the conventional
RNG include mechanism: If you want to include for ex.
http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_allPlus.rng 
and override the ref attribute on name, if name has the type="person",
you’d have to fork the 'tei_name', 'tei_att.personal.attributes',
'tei_att.naming.attributes', 'tei_att.canonical.attributes', and
'tei_att.canonical.attribute.ref' patterns. This is doable, but if you
want to support multiple overlapping constraints, you end up with plenty
of pattern variants quickly. And you need to analyze first which
patterns you need to override.

With epischemas, you just pile them up one by one without ever bothering
about the base schema and its building blocks.

Gerrit



On 29.05.2018 13:56, Elisa Beshero-Bondar wrote:

> Gerrit-- I'm eager to experiment with Epischemas, and I agree that it
> would be great to see these implemented in ODDs, since content
> completion is certainly helpful. One of my projects includes a giant
> file or prosopography lists containing hundreds of xml:ids, and my
> Schematron solutions, while quick for me to implement, don't necessarily
> help contributors to the project to select the right ids for the right
> elements.
>
> One thing I need to implement in my ODD for this giant project is a good
> mechanism for updating the ODD with new ids as they're added (so I don't
> have to do this myself). XSLT can do the job, but so can
> Schematron--though without anything like content completion. I wonder if
> the NVDL might be a good solution to sit alongside the ODD? I'm curious
> to learn more about this as I'm still trying to find the right solution
> for this big project!
>
> Cheers,
> Elisa
>
> On Tue, May 29, 2018 at 5:45 AM, Imsieke, Gerrit, le-tex
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hi Sean,
>
>     I agree if the presupposition is to maintain an ODD in the first place.
>
>     However, there are people (like us, many of our customers, or DFG
>     [1]) who want to have some baseline compliance with a widespread TEI
>     customization and then add their constraints. These people sometimes
>     don’t deal with ODD at all, and I think it isn’t yet illegal to do so.
>
>     On the other hand, it is desirable to express co-occurrence
>     constraints in ODD, too. This is what I was trying to say in the
>     last paragraph of the previous message. Once there are means for
>     expressing these constraints in ODD, users should be able to have an
>     option to generate either
>     – Embedded Schematron rules,
>     – an External Schematron file,
>     – both Schematron variants, but with Schematron Quick Fixes, or
>     – a base schema with Epischemas, wrapped in NVDL
>     – a imported RNG schema with overrides to accommodate the
>     constraints (this may become messy though – as Eric van der Vlist
>     wrote, restricting grammar-like schemas is not easy if they lack the
>     granularity [2]).
>
>     As I said, the epischema approach has the advantage of allowing
>     content completion out of the box, which is quite useful in many
>     situations.
>
>     Users who rely on ODD to maintain their customizations need to wait
>     until someone proposes amendments for expressing co-occurrence
>     constraints in ODD and until someone adapts the schema-generating
>     XSLT in order to support epischemas.
>
>     Gerrit
>
>     [1]
>     http://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/foerderkriterien_editionen_literaturwissenschaft.pdf
>     <http://www.dfg.de/download/pdf/foerderung/antragstellung/forschungsdaten/foerderkriterien_editionen_literaturwissenschaft.pdf>
>     [2]
>     http://books.xmlschemata.org/relaxng/relax-CHP-12-SECT-1.html#relax-CHP-12-SECT-1.3
>     <http://books.xmlschemata.org/relaxng/relax-CHP-12-SECT-1.html#relax-CHP-12-SECT-1.3>
>
>
>     On 29.05.2018 11:11, Winslow, Sean Michael ([hidden email]
>     <mailto:[hidden email]>) wrote:
>
>         Gerrit,
>
>         Adding the constraints in Relax NG seems to defeat the purpose
>         of making an ODD, doesn't it? Suddenly, one document does not do
>         it all, and two documents are needed, one to describe the
>         document as TEI and document it, and one to add the constraints
>         to an already-transformed version of the first. It also risks
>         someone getting their hands on and transforming the ODD without
>         the constraints.
>
>         Best,
>
>         -Sean
>
>         Dr Sean M Winslow
>         Zentrum für Informationsmodellierung
>         eMail: [hidden email] <mailto:[hidden email]>
>
>
>
>         -----Ursprüngliche Nachricht-----
>         Von: TEI (Text Encoding Initiative) public discussion list
>         <[hidden email] <mailto:[hidden email]>> Im
>         Auftrag von Imsieke, Gerrit, le-tex
>         Gesendet: Dienstag, 29. Mai 2018 01:19
>         An: [hidden email] <mailto:[hidden email]>
>         Betreff: Re: subtypes of types
>
>         Hi Elisa and Sean,
>
>         Co-occurrence constraints are in fact a job for MY favorite
>         schema language, and that is Relax NG.
>
>         ODD does not (yet) provide native co-occurrence constraints
>         (apart from embedded Schematron), and this is where I, as a TEI
>         outsider and as a native Relax NG speaker, recommend filtering a
>         base TEI schema by another Relax NG schema that permits
>         everything except the type/subtype constraints.
>
>         A benefit of this approach is: In contrast to Schematron (that
>         only checks validity retroactively), it gives you excellent
>         content completion in oXygen (versions 19.0 or newer).
>
>         This is the NVDL that implements your constraint on top of a TEI
>         allPlus base schema:
>         https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_subtypes.nvdl
>         <https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_subtypes.nvdl>
>         If you are using oXygen, you can prepend the following xml-model
>         PI to your document:
>         <?xml-model
>         href="https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_subtypes.nvdl
>         <https://subversion.le-tex.de/common/schema/tei-cssa/tei_allPlus_subtypes.nvdl>"
>
>               type="application/xml"
>         schematypens="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0
>         <http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0>"?>
>
>         You see in the NVDL that you can refer to any base schema, and
>         this is another nice property of this approach: It is
>         orthogonal, it does not depend on knowledge of the inner
>         building blocks (named patterns) of your base schema.
>         (Schematron, of course, is also orthogonal to the base schema in
>         that it does not need to know about the names and the
>         granularity of the base schema patterns.)
>
>         This NVDL is an example of the “epischema” approach that I
>         presented at XML Prague 2017:
>         http://archive.xmlprague.cz/2017/files/presentations/epischema/index.html#/
>         <http://archive.xmlprague.cz/2017/files/presentations/epischema/index.html#/>
>
>         The epischema itself is at
>         https://subversion.le-tex.de/common/schema/tei-cssa/subtypes.rng
>         <https://subversion.le-tex.de/common/schema/tei-cssa/subtypes.rng>
>         Of course it is a bit contrived, but no more so than your example ;)
>
>         I’m aware that most TEI users will only start using this
>         approach when they can generate a complete NVDL with constraints
>         from an ODD specification. I’m afraid that finding an adequate
>         “grammar constraint”
>         vocabulary for ODD may already be difficult, let alone
>         generating from ODD the RNG epischemas that implement these
>         constraints.
>
>         Gerrit
>
>
>         On 28.05.2018 17:26, Elisa Beshero-Bondar wrote:
>
>             Hi Sean,
>             This is a job for my favorite type of schema language,
>             Schematron, and
>             it's available inside ODD, though a little tricky to write.
>             Schematron
>             allows for definitions of schema rules based on XPath
>             relationships,
>             so you basically write a test to say when your @type
>             attribute is set
>             to "A", the @subtype on the same element must be A1, A2, or
>             A3. I'll
>             post an example or two, here--it helps to see how these are
>             defined in
>             a functioning ODD, and we really need more available examples of
>             Schematron use in ODDs.
>
>             Cheers,
>             Elisa
>
>
>
>             On Mon, May 28, 2018 at 11:11 AM, Winslow, Sean Michael
>             ([hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email]
>             <mailto:[hidden email]>>)
>             <[hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email]
>             <mailto:[hidden email]>>> wrote:
>
>                   All,____
>
>                   __ __
>
>                   If in TEI, if I have a list of @type values:____
>
>                   A, B, C____
>
>                   And @subtypes of those values:____
>
>                   A: A1, A2, A3____
>
>                   B: B4, B5____
>
>                   C: C6, C7____
>
>                   How do I represent the link between the @subtype and
>             @type in the
>                   ODD? There doesn’t seem to be an example in the
>             documentation that I
>                   can find.____
>
>                   __ __
>
>                   <valListtype="closed">
>                   <valItemident="A">
>                   <desc>A has three subtypes, A1, A2, A3</desc>
>                   </valItem>
>                   <valItemident="B">
>                   <desc>A has two subtypes, B4, B5</desc>
>                   </valItem>
>                   <valItemident="C">
>                   <desc>A has two subtypes, C6, C7</desc>
>                   </valItem>____
>
>                   </valList>____
>
>                   __ __
>
>                   I wpould think I would nest a valList inside the
>             relevant valItem,
>                   but this does not seem to be allowed by valItem. ____
>
>                   __ __
>
>                   <valListtype="closed">
>                   <valItemident="A">
>                   <desc>A has three subtypes, A1, A2, A3</desc>____
>
>                   <attDefident="subtype"mode="replace">____
>
>                   <valListtype="closed">
>                   <valItemident="A1">
>                   </valItem>
>                   <valItemident="A2">
>                   </valItem>
>                   <valItemident="A3">
>                   </valItem>____
>
>                   </valList>____
>
>                   </attDef>
>                   </valItem>____
>
>                   __ __
>
>                   Gives : element "attDef" not allowed here; expected
>             the element
>                   end-tag or element "altIdent", "desc", "equiv",
>             "gloss", "paramList"
>                   or "remarks"____
>
>                   __ __
>
>                   What is the intended way to define @subtype lists?____
>
>                   __ __
>
>                   Many Thanks,____
>
>                   __ __
>
>                   -Sean____
>
>                   __ __
>
>                   __ __
>
>                   Dr Sean M Winslow
>                   Zentrum für Informationsmodellierung
>                   Austrian Centre for Digital Humanities
>                   Karl-Franzens-Universität Graz
>                   A-8010 Graz | Elisabethstraße 59
>                
>               <https://maps.google.com/?q=Elisabethstra%C3%9Fe+59&entry=gmail&source <https://maps.google.com/?q=Elisabethstra%C3%9Fe+59&entry=gmail&source>
>             =g>/III
>
>                   Tel: +43 316 380 5772
>                   eMail: [hidden email]
>             <mailto:[hidden email]>
>             <mailto:[hidden email]
>             <mailto:[hidden email]>>
>                   Web: informationsmodellierung.uni-graz.at
>             <http://informationsmodellierung.uni-graz.at>
>                   <http://informationsmodellierung.uni-graz.at
>             <http://informationsmodellierung.uni-graz.at>>____
>
>                   __ __
>
>
>
>
>             --
>             Elisa Beshero-Bondar, PhD
>             Director, Center for the Digital Text | Associate Professor
>             of English
>             University of Pittsburgh at Greensburg | Humanities Division
>             150 Finoli Drive
>             Greensburg, PA  15601  USA
>             E-mail: [hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>> Development site:
>             http://newtfire.org <http://newtfire.org/>
>
>
>         --
>         Gerrit Imsieke
>         Geschäftsführer / Managing Director
>         le-tex publishing services GmbH
>         Weissenfelser Str. 84, 04229 Leipzig, Germany Phone +49 341
>         355356 110, Fax +49 341 355356 510 [hidden email]
>         <mailto:[hidden email]>, http://www.le-tex.de
>
>         Registergericht / Commercial Register: Amtsgericht Leipzig
>         Registernummer / Registration Number: HRB 24930
>
>         Geschäftsführer / Managing Directors:
>         Gerrit Imsieke, Svea Jelonek, Thomas Schmidt
>
>
>     --
>     Gerrit Imsieke
>     Geschäftsführer / Managing Director
>     le-tex publishing services GmbH
>     Weissenfelser Str. 84, 04229 Leipzig, Germany
>     Phone +49 341 355356 110, Fax +49 341 355356 510
>     [hidden email] <mailto:[hidden email]>,
>     http://www.le-tex.de
>
>     Registergericht / Commercial Register: Amtsgericht Leipzig
>     Registernummer / Registration Number: HRB 24930
>
>     Geschäftsführer / Managing Directors:
>     Gerrit Imsieke, Svea Jelonek, Thomas Schmidt
>
>
>
>
> --
> Elisa Beshero-Bondar, PhD
> Director, Center for the Digital Text | Associate Professor of English
> University of Pittsburgh at Greensburg | Humanities Division
> 150 Finoli Drive
> Greensburg, PA  15601  USA
> E-mail: [hidden email] <mailto:[hidden email]>
> Development site: http://newtfire.org <http://newtfire.org/>

--
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
[hidden email], http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

Geschäftsführer / Managing Directors:
Gerrit Imsieke, Svea Jelonek, Thomas Schmidt
Reply | Threaded
Open this post in threaded view
|

Re: subtypes of types

James Cummings-5
In reply to this post by Winslow, Sean Michael (sean.winslow@uni-graz.at)

Hi Sean,


Notwithstanding the interesting discussions of how to improve the pure ODD language (some of which may be inspired because of the way people write ODDs rather than the ODD language itself), if you are doing this relationship between A, A1, A2, A3 and B, B1, B2, B3, etc all on the type and subtype attribute, are you sure the type attribute is the kind of classification you want to be using?  When I see people doing what they often want is the kind of hierarchical classification you get from using the ana attribute to point to an arbitrarily-deeply nested category element. i.e. pointing to A.1.3 and getting that this element is classified as A.1.3, A.1, and A. 


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 Winslow, Sean Michael ([hidden email]) <[hidden email]>
Sent: 28 May 2018 16:11
To: [hidden email]
Subject: subtypes of types
 

All,

 

If in TEI, if I have a list of @type values:

A, B, C

And @subtypes of those values:

A: A1, A2, A3

B: B4, B5

C: C6, C7

How do I represent the link between the @subtype and @type in the ODD? There doesn’t seem to be an example in the documentation that I can find.

 

<valList type="closed">
        
<valItem ident="A">
         
<desc>A has three subtypes, A1, A2, A3</desc>
        
</valItem>
        
<valItem ident="B">
         
<desc>A has two subtypes, B4, B5</desc>
        
</valItem>
        
<valItem ident="C">
         
<desc>A has two subtypes, C6, C7</desc>
        
</valItem>

</valList>

 

I wpould think I would nest a valList inside the relevant valItem, but this does not seem to be allowed by valItem.

 

<valList type="closed">
        
<valItem ident="A">
         
<desc>A has three subtypes, A1, A2, A3</desc>

<attDef ident="subtype" mode="replace">

<valList type="closed">
              
<valItem ident="A1">
              
</valItem>
              
<valItem ident="A2">
              
</valItem>
              
<valItem ident="A3">
              
</valItem>

</valList>

</attDef>
        
</valItem>

 

Gives : element "attDef" not allowed here; expected the element end-tag or element "altIdent", "desc", "equiv", "gloss", "paramList" or "remarks"

 

What is the intended way to define @subtype lists?

 

Many Thanks,

 

-Sean

 

 

Dr Sean M Winslow
Zentrum für Informationsmodellierung
Austrian Centre for Digital Humanities
Karl-Franzens-Universität Graz
A-8010 Graz | Elisabethstraße 59/III
 
Tel: +43 316 380 5772
[hidden email]
Web: informationsmodellierung.uni-graz.at