Trojan Horse markup in TEI - three questions

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

Trojan Horse markup in TEI - three questions

C. M. Sperberg-McQueen
In connection with a project I am working on [1], I find myself with a
few questions for which readers of this list may have useful answers.

I apologize for the length of the message; I have tried to explain
things that might not be universal knowledge, which takes space.  If
you get lost in the thicket, a string search for 'question' will find
the questions I am trying to pose.


I Our particular flavor of the overlap problem

The project is transcribing a number of unpublished manuscripts (as
many as we have resources to transcribe) and providing linguistic
annotation and English translations for some (as many as we have
resources to annotate).  The curious reader can see some of our
initial transcriptions at [2]; we do not currently have any published
documents with translations and/or annotation.  (Partly because I
haven't yet solved the problem I am describing here.)

We would like to be able to view (and process) documents either (a) in
the customized TEI built around sourceDoc, page, zone, and line which
we are using for the initial transcription of manuscript), or (b) in a
different customized TEI built around text, p, and s (for prose; text,
lg, and l, for verse).  We would like to be able to convert documents
between these two flavors of TEI without loss of information (so that
as we find and fix errors or enrich the markup in either view, we can
update the other view automatically).

Since the page/zone/line structure of the one form and the
text/paragraph/sentence structure of the other do not nest, we have
the challenge of recording two structures in a single XML document.
(We choose not to make it two separate documents in order to avoid
synchronization issues.)  In our situation, unlike that in some
projects, each of the two structures is easily realizable as a
perfectly ordinary XML element structure; if we were using SGML, the
CONCUR feature would cover our needs nicely.

Question 1 When other projects have faced similar situations, what
techniques have you used to organize the markup?  Do you have advice
for us?


II A tentative solution (Trojan Horse markup)

The simplest general solution I know to this particular form of the
overlap problem is the technique described by Steve DeRose in 2004
under the name Trojan Horse markup [3].  This is a generalization both
of the similar technique used by the Anglo-Saxonist David Megginson in
the 1980s which I like to call "Megginson Grammars" (described in [4])
and also in a different way a generalization of the TEI 'milestone'
element [5].

In Trojan Horse markup, some textual structures are represented by
single XML elements in the conventional way; others (specifically
those which don't nest within the element structure thus defined) are
represented by two co-indexed empty XML elements, one representing the
start of the textual structure and the other representing its end.
Trojan Horse markup differs from Megginson grammars in providing
explicit end-tags; it differs from the TEI 'milestone' element in not
using a dedicated element type but instead using the same element type
to represent conventional instances of a structure and the
Trojan-Horse instances. In the following example adapted from [3], the
'sID' and 'eID' attributes on the 'q' elements identify the tags which
bear them as Trojan Horse markup and co-index the start and end of
each element.

    <div>
      <p>
        <verse osisID="Jer.2.1">Moreover the word
          of the LORD came to me, saying,</verse>
        <verse osisID="Jer.2.2">
          <q sID="Q-Jer.2.2-A"/>Go and cry in the
          hearing of Jerusalem, saying,
            <q sID="Q-Jer.2.2-B"/>Thus says the LORD:
              <q sID="Q-Jer.2.2-C"/>I remember you,
              The kindness of your youth, The love of your
              betrothal, When you went after Me in the
              wilderness, In a land not sown.
        </verse>
        <verse osisID="Jer.2.3">        
              Israel [was] holiness
              to the LORD, The firstfruits of His increase.  All
              that devour him will offend; Disaster
              will come upon them,<q eID="Q-Jer.2.2-C"/>
            says the LORD. <q eID="Q-Jer.2.2-B"/>
        </verse>
        ...
      </p>
      <p>
        ... <q eID="Q-Jer.2.2-A"/>
      </p>
      ...
    </div>

In a situation like ours where CONCUR would work fine, the co-indexing
is strictly speaking redundant, but the co-indexing helps reassure me
that my transformation has not messed anything up beyond repair.

In order to use an element (like 'q' in the example) as a Trojan Horse
tag, the schema needs to be doctored, so that

  (a) Valid instances of the element can be empty.  (In the case of
  elements present only in the secondary text structure, I'd want the
  schema to require valid instances of the element to be empty.)

  (b) Valid instances (ideally only empty ones) can carry either an
  sID or an eID attribute.  Ideally, if eID is present all other
  attributes will be invalid.

In the use of Trojan Horse markup foreseen by Steve DeRose, the
content models of potential parents need not be modified: Trojan Horse
tags for the 'q' element should be valid wherever a normal 'q' would
be valid, and nowhere else.  In our situation, however, the elements
of the secondary document structure should not be constrained by the
primary document structure, so their Trojan Horse milestone forms need
to be legal more or less everywhere, which means that many or all of
the content models for the primary document structure should be
modified so that

  (c) The Trojan Horse markup for any element in the secondary
  document structure can validly appear at essentially any point in
  the primary structure.

(In this context, for the first time in twenty years or so, I miss
SGML's inclusion exceptions; they would at least make it easy to allow
the Trojan Horse markup for the secondary structure everywhere.)  In
the ideal case, I'd like context-specific declarations for elements
like 'p': in the document body, 'p' should be able to contain Trojan
Horse markup for tei:zone (etc.), but not in the header.

It seems self-evident that it is a subtle but essentially mechanical
process to modify a schema to handle the sID and eID attributes, allow
Trojan Horse elements to be empty, and allow Trojan Horse elements to
appear pretty much everywhere.  Because it's subtle, I'd rather not do
it by hand if I can avoid it.  Because it's mechanical, I think I can
avoid it.

Question 2:  do any readers of this list have (or know of) tools for
this kind of operations on schemas or ODD documents?


III Planning for the future

Unless I am surprised by unexpected answers to questions 1 or 2 and
led to change my plans, my current expectation is that I will develop
the needed infrastructure in several stages.

I'll probably start with a variant of Trojan Horse markup which
requires no schema changes (because it places the start- and end-tags
of the secondary structure into processing instructions or structured
comments).  Using this variant, I'll:

  1 Write a stylesheet to translate reduce the start- and end-tags of
  the primary structure to Trojan Horse milestones, within some
  context (here: within /TEI/sourceDoc and /TEI/text).

  2 Write a stylesheet to identify the milestones for a given
  secondary structure and make it the primary structure (accepting the
  output of the first stylesheet as its input).

The result can be thought of as a cheap XML version of CONCUR.

I'll then move to Trojan Horse markup proper (or possibly to that uses
a single element -- analogous to TEI 'milestone', but with a different
design).  In addition to updating the two stylesheets mentioned above,
this will require

  3 A transformation to operate on a schema (better, an ODD document,
  but that seems likely to be too challenging) to modify declarations
  for specified elements, making them either (a) capable of appearing
  validly either as 'normal' elements or as Trojan Horse milestones,
  or (b) capable of appearing validly only as milestones.

  4 A transformation to operate on a schema (again, better an ODD
  document, if I could see how) to modify declarations for specified
  elements, making allowing Trojan Horse milestones to appear anywhere
  within them.  (The content-model modification technique to be used
  here is the same as for the elimination of content-model inclusions
  in the TEI after the development of XML; definitely automatable.)

I do not expect at this time to attempt to automate a schema-level
distinction between contexts in which Trojan Horse markup should be
allowed and those in which it is not allowed.  A Schematron rule can
do that fairly simply, so making the distinction by means of the
document grammar seems unnecessary.  (An interesting challenge,
perhaps, but not part of the minimum required to declare victory.)

This leads to question 3:  Is the tool chain I am describing likely to
be of interest to any others in the TEI community?

If so, please let me know.  If you have specific suggestions,
requirements, or desiderata for such a tool chain, I'd like to know
those, too.  I don't expect TEI-L to be the best place for a
discussion of such requirements, but if I hear from anyone I will send
a summary of the results to the list, for future reference.

With thanks for the patience of any readers who have made it this far
into this mail,

Michael Sperberg-McQueen


[1] http://uyghur.ittc.ku.edu/atmo.html
[2] http://uyghur.ittc.ku.edu/manuscripts/index.xhtml#tr
[3] http://conferences.idealliance.org/extreme/html/2004/DeRose01/EML2004DeRose01.html
[4] http://conferences.idealliance.org/extreme/html/2006/SperbergMcQueen01/EML2006SperbergMcQueen01.html
[5] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#CORS5

********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
[hidden email]
http://www.blackmesatech.com
********************************************
Reply | Threaded
Open this post in threaded view
|

SV: Trojan Horse markup in TEI - three questions

Sigfrid Lundberg
Good morning,

Far too strong emotions at an early morning before a cup of strong coffee.

I wrote the first version of the software running at the now defunct Gunnar Jarring service.

We served it from the same server as St Laurentius digital manuscript library, which is also gone. Some of the material has moved to Uppsala, I think.

I moved to Copehagen, so we are both gone, Gunnar and I. Suppose I need to prepare for retirement. The links to laurentius are all dead now without redirect (such as http://laurentius.ub.lu.se/jarring/volumes/535.html)

I might have some of the data, not the images though.

Cheers,

Sigfrid


________________________________________
Fra: TEI (Text Encoding Initiative) public discussion list [[hidden email]] på vegne af C. M. Sperberg-McQueen [[hidden email]]
Sendt: 25. oktober 2017 22:24
Til: [hidden email]
Emne: Trojan Horse markup in TEI - three questions

In connection with a project I am working on [1], I find myself with a
few questions for which readers of this list may have useful answers.

I apologize for the length of the message; I have tried to explain
things that might not be universal knowledge, which takes space.  If
you get lost in the thicket, a string search for 'question' will find
the questions I am trying to pose.


I Our particular flavor of the overlap problem

The project is transcribing a number of unpublished manuscripts (as
many as we have resources to transcribe) and providing linguistic
annotation and English translations for some (as many as we have
resources to annotate).  The curious reader can see some of our
initial transcriptions at [2]; we do not currently have any published
documents with translations and/or annotation.  (Partly because I
haven't yet solved the problem I am describing here.)

We would like to be able to view (and process) documents either (a) in
the customized TEI built around sourceDoc, page, zone, and line which
we are using for the initial transcription of manuscript), or (b) in a
different customized TEI built around text, p, and s (for prose; text,
lg, and l, for verse).  We would like to be able to convert documents
between these two flavors of TEI without loss of information (so that
as we find and fix errors or enrich the markup in either view, we can
update the other view automatically).

Since the page/zone/line structure of the one form and the
text/paragraph/sentence structure of the other do not nest, we have
the challenge of recording two structures in a single XML document.
(We choose not to make it two separate documents in order to avoid
synchronization issues.)  In our situation, unlike that in some
projects, each of the two structures is easily realizable as a
perfectly ordinary XML element structure; if we were using SGML, the
CONCUR feature would cover our needs nicely.

Question 1 When other projects have faced similar situations, what
techniques have you used to organize the markup?  Do you have advice
for us?


II A tentative solution (Trojan Horse markup)

The simplest general solution I know to this particular form of the
overlap problem is the technique described by Steve DeRose in 2004
under the name Trojan Horse markup [3].  This is a generalization both
of the similar technique used by the Anglo-Saxonist David Megginson in
the 1980s which I like to call "Megginson Grammars" (described in [4])
and also in a different way a generalization of the TEI 'milestone'
element [5].

In Trojan Horse markup, some textual structures are represented by
single XML elements in the conventional way; others (specifically
those which don't nest within the element structure thus defined) are
represented by two co-indexed empty XML elements, one representing the
start of the textual structure and the other representing its end.
Trojan Horse markup differs from Megginson grammars in providing
explicit end-tags; it differs from the TEI 'milestone' element in not
using a dedicated element type but instead using the same element type
to represent conventional instances of a structure and the
Trojan-Horse instances. In the following example adapted from [3], the
'sID' and 'eID' attributes on the 'q' elements identify the tags which
bear them as Trojan Horse markup and co-index the start and end of
each element.

    <div>
      <p>
        <verse osisID="Jer.2.1">Moreover the word
          of the LORD came to me, saying,</verse>
        <verse osisID="Jer.2.2">
          <q sID="Q-Jer.2.2-A"/>Go and cry in the
          hearing of Jerusalem, saying,
            <q sID="Q-Jer.2.2-B"/>Thus says the LORD:
              <q sID="Q-Jer.2.2-C"/>I remember you,
              The kindness of your youth, The love of your
              betrothal, When you went after Me in the
              wilderness, In a land not sown.
        </verse>
        <verse osisID="Jer.2.3">
              Israel [was] holiness
              to the LORD, The firstfruits of His increase.  All
              that devour him will offend; Disaster
              will come upon them,<q eID="Q-Jer.2.2-C"/>
            says the LORD. <q eID="Q-Jer.2.2-B"/>
        </verse>
        ...
      </p>
      <p>
        ... <q eID="Q-Jer.2.2-A"/>
      </p>
      ...
    </div>

In a situation like ours where CONCUR would work fine, the co-indexing
is strictly speaking redundant, but the co-indexing helps reassure me
that my transformation has not messed anything up beyond repair.

In order to use an element (like 'q' in the example) as a Trojan Horse
tag, the schema needs to be doctored, so that

  (a) Valid instances of the element can be empty.  (In the case of
  elements present only in the secondary text structure, I'd want the
  schema to require valid instances of the element to be empty.)

  (b) Valid instances (ideally only empty ones) can carry either an
  sID or an eID attribute.  Ideally, if eID is present all other
  attributes will be invalid.

In the use of Trojan Horse markup foreseen by Steve DeRose, the
content models of potential parents need not be modified: Trojan Horse
tags for the 'q' element should be valid wherever a normal 'q' would
be valid, and nowhere else.  In our situation, however, the elements
of the secondary document structure should not be constrained by the
primary document structure, so their Trojan Horse milestone forms need
to be legal more or less everywhere, which means that many or all of
the content models for the primary document structure should be
modified so that

  (c) The Trojan Horse markup for any element in the secondary
  document structure can validly appear at essentially any point in
  the primary structure.

(In this context, for the first time in twenty years or so, I miss
SGML's inclusion exceptions; they would at least make it easy to allow
the Trojan Horse markup for the secondary structure everywhere.)  In
the ideal case, I'd like context-specific declarations for elements
like 'p': in the document body, 'p' should be able to contain Trojan
Horse markup for tei:zone (etc.), but not in the header.

It seems self-evident that it is a subtle but essentially mechanical
process to modify a schema to handle the sID and eID attributes, allow
Trojan Horse elements to be empty, and allow Trojan Horse elements to
appear pretty much everywhere.  Because it's subtle, I'd rather not do
it by hand if I can avoid it.  Because it's mechanical, I think I can
avoid it.

Question 2:  do any readers of this list have (or know of) tools for
this kind of operations on schemas or ODD documents?


III Planning for the future

Unless I am surprised by unexpected answers to questions 1 or 2 and
led to change my plans, my current expectation is that I will develop
the needed infrastructure in several stages.

I'll probably start with a variant of Trojan Horse markup which
requires no schema changes (because it places the start- and end-tags
of the secondary structure into processing instructions or structured
comments).  Using this variant, I'll:

  1 Write a stylesheet to translate reduce the start- and end-tags of
  the primary structure to Trojan Horse milestones, within some
  context (here: within /TEI/sourceDoc and /TEI/text).

  2 Write a stylesheet to identify the milestones for a given
  secondary structure and make it the primary structure (accepting the
  output of the first stylesheet as its input).

The result can be thought of as a cheap XML version of CONCUR.

I'll then move to Trojan Horse markup proper (or possibly to that uses
a single element -- analogous to TEI 'milestone', but with a different
design).  In addition to updating the two stylesheets mentioned above,
this will require

  3 A transformation to operate on a schema (better, an ODD document,
  but that seems likely to be too challenging) to modify declarations
  for specified elements, making them either (a) capable of appearing
  validly either as 'normal' elements or as Trojan Horse milestones,
  or (b) capable of appearing validly only as milestones.

  4 A transformation to operate on a schema (again, better an ODD
  document, if I could see how) to modify declarations for specified
  elements, making allowing Trojan Horse milestones to appear anywhere
  within them.  (The content-model modification technique to be used
  here is the same as for the elimination of content-model inclusions
  in the TEI after the development of XML; definitely automatable.)

I do not expect at this time to attempt to automate a schema-level
distinction between contexts in which Trojan Horse markup should be
allowed and those in which it is not allowed.  A Schematron rule can
do that fairly simply, so making the distinction by means of the
document grammar seems unnecessary.  (An interesting challenge,
perhaps, but not part of the minimum required to declare victory.)

This leads to question 3:  Is the tool chain I am describing likely to
be of interest to any others in the TEI community?

If so, please let me know.  If you have specific suggestions,
requirements, or desiderata for such a tool chain, I'd like to know
those, too.  I don't expect TEI-L to be the best place for a
discussion of such requirements, but if I hear from anyone I will send
a summary of the results to the list, for future reference.

With thanks for the patience of any readers who have made it this far
into this mail,

Michael Sperberg-McQueen


[1] http://uyghur.ittc.ku.edu/atmo.html
[2] http://uyghur.ittc.ku.edu/manuscripts/index.xhtml#tr
[3] http://conferences.idealliance.org/extreme/html/2004/DeRose01/EML2004DeRose01.html
[4] http://conferences.idealliance.org/extreme/html/2006/SperbergMcQueen01/EML2006SperbergMcQueen01.html
[5] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#CORS5

********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
[hidden email]
http://www.blackmesatech.com
********************************************
Reply | Threaded
Open this post in threaded view
|

Re: Trojan Horse markup in TEI - three questions

bertrand Gaiffe-2
In reply to this post by C. M. Sperberg-McQueen
There is a point I do not understand in your setting : elements of the secondary structure appear anywhere with respect to the first one, however, if the secondary structure is:
<a><b>......</b>.....</a> do you accept that it translates as:
<b sid.../><a sid..../>.........<b eid.../>......<a eid../> which is "somehow not wellformed".

And, if not, do you accept <b sid/><a>..... <b eid/>... </a> with <a> from the primary structure ?



Envoyé depuis mon appareil mobile Samsung.

-------- Message d'origine --------
De : "C. M. Sperberg-McQueen" <[hidden email]>
Date : 25/10/2017 22:24 (GMT+01:00)
Objet : Trojan Horse markup in TEI - three questions

In connection with a project I am working on [1], I find myself with a
few questions for which readers of this list may have useful answers.

I apologize for the length of the message; I have tried to explain
things that might not be universal knowledge, which takes space.  If
you get lost in the thicket, a string search for 'question' will find
the questions I am trying to pose.


I Our particular flavor of the overlap problem

The project is transcribing a number of unpublished manuscripts (as
many as we have resources to transcribe) and providing linguistic
annotation and English translations for some (as many as we have
resources to annotate).  The curious reader can see some of our
initial transcriptions at [2]; we do not currently have any published
documents with translations and/or annotation.  (Partly because I
haven't yet solved the problem I am describing here.)

We would like to be able to view (and process) documents either (a) in
the customized TEI built around sourceDoc, page, zone, and line which
we are using for the initial transcription of manuscript), or (b) in a
different customized TEI built around text, p, and s (for prose; text,
lg, and l, for verse).  We would like to be able to convert documents
between these two flavors of TEI without loss of information (so that
as we find and fix errors or enrich the markup in either view, we can
update the other view automatically).

Since the page/zone/line structure of the one form and the
text/paragraph/sentence structure of the other do not nest, we have
the challenge of recording two structures in a single XML document.
(We choose not to make it two separate documents in order to avoid
synchronization issues.)  In our situation, unlike that in some
projects, each of the two structures is easily realizable as a
perfectly ordinary XML element structure; if we were using SGML, the
CONCUR feature would cover our needs nicely.

Question 1 When other projects have faced similar situations, what
techniques have you used to organize the markup?  Do you have advice
for us?


II A tentative solution (Trojan Horse markup)

The simplest general solution I know to this particular form of the
overlap problem is the technique described by Steve DeRose in 2004
under the name Trojan Horse markup [3].  This is a generalization both
of the similar technique used by the Anglo-Saxonist David Megginson in
the 1980s which I like to call "Megginson Grammars" (described in [4])
and also in a different way a generalization of the TEI 'milestone'
element [5].

In Trojan Horse markup, some textual structures are represented by
single XML elements in the conventional way; others (specifically
those which don't nest within the element structure thus defined) are
represented by two co-indexed empty XML elements, one representing the
start of the textual structure and the other representing its end.
Trojan Horse markup differs from Megginson grammars in providing
explicit end-tags; it differs from the TEI 'milestone' element in not
using a dedicated element type but instead using the same element type
to represent conventional instances of a structure and the
Trojan-Horse instances. In the following example adapted from [3], the
'sID' and 'eID' attributes on the 'q' elements identify the tags which
bear them as Trojan Horse markup and co-index the start and end of
each element.

    <div>
      <p>
        <verse osisID="Jer.2.1">Moreover the word
          of the LORD came to me, saying,</verse>
        <verse osisID="Jer.2.2">
          <q sID="Q-Jer.2.2-A"/>Go and cry in the
          hearing of Jerusalem, saying,
            <q sID="Q-Jer.2.2-B"/>Thus says the LORD:
              <q sID="Q-Jer.2.2-C"/>I remember you,
              The kindness of your youth, The love of your
              betrothal, When you went after Me in the
              wilderness, In a land not sown.
        </verse>
        <verse osisID="Jer.2.3">       
              Israel [was] holiness
              to the LORD, The firstfruits of His increase.  All
              that devour him will offend; Disaster
              will come upon them,<q eID="Q-Jer.2.2-C"/>
            says the LORD. <q eID="Q-Jer.2.2-B"/>
        </verse>
        ...
      </p>
      <p>
        ... <q eID="Q-Jer.2.2-A"/>
      </p>
      ...
    </div>

In a situation like ours where CONCUR would work fine, the co-indexing
is strictly speaking redundant, but the co-indexing helps reassure me
that my transformation has not messed anything up beyond repair.

In order to use an element (like 'q' in the example) as a Trojan Horse
tag, the schema needs to be doctored, so that

  (a) Valid instances of the element can be empty.  (In the case of
  elements present only in the secondary text structure, I'd want the
  schema to require valid instances of the element to be empty.)

  (b) Valid instances (ideally only empty ones) can carry either an
  sID or an eID attribute.  Ideally, if eID is present all other
  attributes will be invalid.

In the use of Trojan Horse markup foreseen by Steve DeRose, the
content models of potential parents need not be modified: Trojan Horse
tags for the 'q' element should be valid wherever a normal 'q' would
be valid, and nowhere else.  In our situation, however, the elements
of the secondary document structure should not be constrained by the
primary document structure, so their Trojan Horse milestone forms need
to be legal more or less everywhere, which means that many or all of
the content models for the primary document structure should be
modified so that

  (c) The Trojan Horse markup for any element in the secondary
  document structure can validly appear at essentially any point in
  the primary structure.

(In this context, for the first time in twenty years or so, I miss
SGML's inclusion exceptions; they would at least make it easy to allow
the Trojan Horse markup for the secondary structure everywhere.)  In
the ideal case, I'd like context-specific declarations for elements
like 'p': in the document body, 'p' should be able to contain Trojan
Horse markup for tei:zone (etc.), but not in the header.

It seems self-evident that it is a subtle but essentially mechanical
process to modify a schema to handle the sID and eID attributes, allow
Trojan Horse elements to be empty, and allow Trojan Horse elements to
appear pretty much everywhere.  Because it's subtle, I'd rather not do
it by hand if I can avoid it.  Because it's mechanical, I think I can
avoid it.

Question 2:  do any readers of this list have (or know of) tools for
this kind of operations on schemas or ODD documents?


III Planning for the future

Unless I am surprised by unexpected answers to questions 1 or 2 and
led to change my plans, my current expectation is that I will develop
the needed infrastructure in several stages.

I'll probably start with a variant of Trojan Horse markup which
requires no schema changes (because it places the start- and end-tags
of the secondary structure into processing instructions or structured
comments).  Using this variant, I'll:

  1 Write a stylesheet to translate reduce the start- and end-tags of
  the primary structure to Trojan Horse milestones, within some
  context (here: within /TEI/sourceDoc and /TEI/text).

  2 Write a stylesheet to identify the milestones for a given
  secondary structure and make it the primary structure (accepting the
  output of the first stylesheet as its input).

The result can be thought of as a cheap XML version of CONCUR.

I'll then move to Trojan Horse markup proper (or possibly to that uses
a single element -- analogous to TEI 'milestone', but with a different
design).  In addition to updating the two stylesheets mentioned above,
this will require

  3 A transformation to operate on a schema (better, an ODD document,
  but that seems likely to be too challenging) to modify declarations
  for specified elements, making them either (a) capable of appearing
  validly either as 'normal' elements or as Trojan Horse milestones,
  or (b) capable of appearing validly only as milestones.

  4 A transformation to operate on a schema (again, better an ODD
  document, if I could see how) to modify declarations for specified
  elements, making allowing Trojan Horse milestones to appear anywhere
  within them.  (The content-model modification technique to be used
  here is the same as for the elimination of content-model inclusions
  in the TEI after the development of XML; definitely automatable.)

I do not expect at this time to attempt to automate a schema-level
distinction between contexts in which Trojan Horse markup should be
allowed and those in which it is not allowed.  A Schematron rule can
do that fairly simply, so making the distinction by means of the
document grammar seems unnecessary.  (An interesting challenge,
perhaps, but not part of the minimum required to declare victory.)

This leads to question 3:  Is the tool chain I am describing likely to
be of interest to any others in the TEI community?

If so, please let me know.  If you have specific suggestions,
requirements, or desiderata for such a tool chain, I'd like to know
those, too.  I don't expect TEI-L to be the best place for a
discussion of such requirements, but if I hear from anyone I will send
a summary of the results to the list, for future reference.

With thanks for the patience of any readers who have made it this far
into this mail,

Michael Sperberg-McQueen


[1] http://uyghur.ittc.ku.edu/atmo.html
[2] http://uyghur.ittc.ku.edu/manuscripts/index.xhtml#tr
[3] http://conferences.idealliance.org/extreme/html/2004/DeRose01/EML2004DeRose01.html
[4] http://conferences.idealliance.org/extreme/html/2006/SperbergMcQueen01/EML2006SperbergMcQueen01.html
[5] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#CORS5

********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
[hidden email]
http://www.blackmesatech.com
********************************************
Reply | Threaded
Open this post in threaded view
|

Re: Trojan Horse markup in TEI - three questions

Raffaele Viglianti-2
In reply to this post by C. M. Sperberg-McQueen
Dear Michael,

We faced a very similar conundrum in the Shelley-Godwin Archive (S-GA) and I have presented about it at the 2013 TEI conference, the Cultural Heritage Markup pre-conference event to 2015 Balisage, and elsewhere. Trevor Muñoz and I have written a summary of the issues in this article: https://jtei.revues.org/1270

To summarize shortly, we have gone with what you're calling a trojan horse solution using <tei:milestone> elements. This worked well for the Frankenstein manuscripts because we simply marked milestones for chapters and paragraphs. However, when we moved to Shelley's Prometheus Unbound (a dramatic poem), things got way out of hand. We began using the @spanTo attribute on tei:milestone to indicate textual structures more effectively (a practice that arguably perverts the semantics of a milestone, but let me remind you that the @spanTo attribute is allowed on the tei:milestone element). This however, turned out to be too chaotic. 

We haven't moved far from this status quo at S-GA and we rely on automatic transformation (written by Wendell Piez and extended in-house) to provide the text-focused version of TEI, from which we then derive a "reading" text of the manuscript (ie resolving authorial revisions -- see the paper for more details).

Nonetheless, we have a plan for implementing a different kind of solution. This is something I have only experimented with, because the current funds for S-GA (which does not have an active grant at the moment) are being spent on expanding the archive's content over the development of new experimental features. Briefly, the idea is to acknowledge that our document-focused encoding (the one under <sourceDoc>) is, and will remain, our primary form of encoding. But this needn't stop us from layering further encoding on top by using a stand-off approach. So we're planning on creating a <text> branch that will make textual structures explicit (with <div>, <p>, <lg>, <sp>, <stage>, etc.), but use pointers to indicate where the character data content is located -- ie in the <sourceDoc> branch. 

A simple example could look like this:

<TEI>
  <teiHeader><!-- header --></teiHeader>
  <sourceDoc>
     <surface>
        <zone>
           <line xml:id="l1">Asia</line>
           <line xml:id="l2">My soul is an enchanted Boat</line>
           <line xml:id="l3">Which, li<mod>
              <del rend="overwritten">f</del>
              <add place="intralinear">k</add>
           </mod>e a sleeping swan, doth <unclear reason="illegible">f</unclear>loat</line>
           <line xml:id="l4">Upon the silver waves of thy sweet singing,</line>
           <!-- etc. -->
        </zone>
     </surface>
  </sourceDoc>
  <text>
      <body>
         <div>
            <sp>
               <speaker>
                  <ptr target="#l1"/>
               </speaker>
               <l><ptr target="#l2"/></l>
               <l><ptr target="#l3"/></l>
               <l><ptr target="#l4"/></l>
               <!-- etc. -->
            </sp>
         </div>
      </body>
  </text>
</TEI>
 
We hope to be able to use XPointer for more complex selections of text. For example if we wanted to resolve the <mod> at line 3 (Based on http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSSR):

<l>
   <ptr target="#string-range(//*[@xml:id='l3'], 0 , 9, 40, 1, 53, 29)"/>
</l>

I spent some time last year writing a UI tool to built these kind of references by area selection: https://raffazizzi.github.io/coreBuilder but hasn't yet been used extensively with XPointer, so bugs are likely.

As I mentioned, this approach to encoding is more of an idea as opposed to anything that we are actively pursuing at the moment; therefore, it hasn't really been stress tested. I would love to hear your thoughts and the list's.

Best wishes,
Raff Viglianti


On Wed, Oct 25, 2017 at 4:24 PM, C. M. Sperberg-McQueen <[hidden email]> wrote:
In connection with a project I am working on [1], I find myself with a
few questions for which readers of this list may have useful answers.

I apologize for the length of the message; I have tried to explain
things that might not be universal knowledge, which takes space.  If
you get lost in the thicket, a string search for 'question' will find
the questions I am trying to pose.


I Our particular flavor of the overlap problem

The project is transcribing a number of unpublished manuscripts (as
many as we have resources to transcribe) and providing linguistic
annotation and English translations for some (as many as we have
resources to annotate).  The curious reader can see some of our
initial transcriptions at [2]; we do not currently have any published
documents with translations and/or annotation.  (Partly because I
haven't yet solved the problem I am describing here.)

We would like to be able to view (and process) documents either (a) in
the customized TEI built around sourceDoc, page, zone, and line which
we are using for the initial transcription of manuscript), or (b) in a
different customized TEI built around text, p, and s (for prose; text,
lg, and l, for verse).  We would like to be able to convert documents
between these two flavors of TEI without loss of information (so that
as we find and fix errors or enrich the markup in either view, we can
update the other view automatically).

Since the page/zone/line structure of the one form and the
text/paragraph/sentence structure of the other do not nest, we have
the challenge of recording two structures in a single XML document.
(We choose not to make it two separate documents in order to avoid
synchronization issues.)  In our situation, unlike that in some
projects, each of the two structures is easily realizable as a
perfectly ordinary XML element structure; if we were using SGML, the
CONCUR feature would cover our needs nicely.

Question 1 When other projects have faced similar situations, what
techniques have you used to organize the markup?  Do you have advice
for us?


II A tentative solution (Trojan Horse markup)

The simplest general solution I know to this particular form of the
overlap problem is the technique described by Steve DeRose in 2004
under the name Trojan Horse markup [3].  This is a generalization both
of the similar technique used by the Anglo-Saxonist David Megginson in
the 1980s which I like to call "Megginson Grammars" (described in [4])
and also in a different way a generalization of the TEI 'milestone'
element [5].

In Trojan Horse markup, some textual structures are represented by
single XML elements in the conventional way; others (specifically
those which don't nest within the element structure thus defined) are
represented by two co-indexed empty XML elements, one representing the
start of the textual structure and the other representing its end.
Trojan Horse markup differs from Megginson grammars in providing
explicit end-tags; it differs from the TEI 'milestone' element in not
using a dedicated element type but instead using the same element type
to represent conventional instances of a structure and the
Trojan-Horse instances. In the following example adapted from [3], the
'sID' and 'eID' attributes on the 'q' elements identify the tags which
bear them as Trojan Horse markup and co-index the start and end of
each element.

    <div>
      <p>
        <verse osisID="Jer.2.1">Moreover the word
          of the LORD came to me, saying,</verse>
        <verse osisID="Jer.2.2">
          <q sID="Q-Jer.2.2-A"/>Go and cry in the
          hearing of Jerusalem, saying,
            <q sID="Q-Jer.2.2-B"/>Thus says the LORD:
              <q sID="Q-Jer.2.2-C"/>I remember you,
              The kindness of your youth, The love of your
              betrothal, When you went after Me in the
              wilderness, In a land not sown.
        </verse>
        <verse osisID="Jer.2.3">
              Israel [was] holiness
              to the LORD, The firstfruits of His increase.  All
              that devour him will offend; Disaster
              will come upon them,<q eID="Q-Jer.2.2-C"/>
            says the LORD. <q eID="Q-Jer.2.2-B"/>
        </verse>
        ...
      </p>
      <p>
        ... <q eID="Q-Jer.2.2-A"/>
      </p>
      ...
    </div>

In a situation like ours where CONCUR would work fine, the co-indexing
is strictly speaking redundant, but the co-indexing helps reassure me
that my transformation has not messed anything up beyond repair.

In order to use an element (like 'q' in the example) as a Trojan Horse
tag, the schema needs to be doctored, so that

  (a) Valid instances of the element can be empty.  (In the case of
  elements present only in the secondary text structure, I'd want the
  schema to require valid instances of the element to be empty.)

  (b) Valid instances (ideally only empty ones) can carry either an
  sID or an eID attribute.  Ideally, if eID is present all other
  attributes will be invalid.

In the use of Trojan Horse markup foreseen by Steve DeRose, the
content models of potential parents need not be modified: Trojan Horse
tags for the 'q' element should be valid wherever a normal 'q' would
be valid, and nowhere else.  In our situation, however, the elements
of the secondary document structure should not be constrained by the
primary document structure, so their Trojan Horse milestone forms need
to be legal more or less everywhere, which means that many or all of
the content models for the primary document structure should be
modified so that

  (c) The Trojan Horse markup for any element in the secondary
  document structure can validly appear at essentially any point in
  the primary structure.

(In this context, for the first time in twenty years or so, I miss
SGML's inclusion exceptions; they would at least make it easy to allow
the Trojan Horse markup for the secondary structure everywhere.)  In
the ideal case, I'd like context-specific declarations for elements
like 'p': in the document body, 'p' should be able to contain Trojan
Horse markup for tei:zone (etc.), but not in the header.

It seems self-evident that it is a subtle but essentially mechanical
process to modify a schema to handle the sID and eID attributes, allow
Trojan Horse elements to be empty, and allow Trojan Horse elements to
appear pretty much everywhere.  Because it's subtle, I'd rather not do
it by hand if I can avoid it.  Because it's mechanical, I think I can
avoid it.

Question 2:  do any readers of this list have (or know of) tools for
this kind of operations on schemas or ODD documents?


III Planning for the future

Unless I am surprised by unexpected answers to questions 1 or 2 and
led to change my plans, my current expectation is that I will develop
the needed infrastructure in several stages.

I'll probably start with a variant of Trojan Horse markup which
requires no schema changes (because it places the start- and end-tags
of the secondary structure into processing instructions or structured
comments).  Using this variant, I'll:

  1 Write a stylesheet to translate reduce the start- and end-tags of
  the primary structure to Trojan Horse milestones, within some
  context (here: within /TEI/sourceDoc and /TEI/text).

  2 Write a stylesheet to identify the milestones for a given
  secondary structure and make it the primary structure (accepting the
  output of the first stylesheet as its input).

The result can be thought of as a cheap XML version of CONCUR.

I'll then move to Trojan Horse markup proper (or possibly to that uses
a single element -- analogous to TEI 'milestone', but with a different
design).  In addition to updating the two stylesheets mentioned above,
this will require

  3 A transformation to operate on a schema (better, an ODD document,
  but that seems likely to be too challenging) to modify declarations
  for specified elements, making them either (a) capable of appearing
  validly either as 'normal' elements or as Trojan Horse milestones,
  or (b) capable of appearing validly only as milestones.

  4 A transformation to operate on a schema (again, better an ODD
  document, if I could see how) to modify declarations for specified
  elements, making allowing Trojan Horse milestones to appear anywhere
  within them.  (The content-model modification technique to be used
  here is the same as for the elimination of content-model inclusions
  in the TEI after the development of XML; definitely automatable.)

I do not expect at this time to attempt to automate a schema-level
distinction between contexts in which Trojan Horse markup should be
allowed and those in which it is not allowed.  A Schematron rule can
do that fairly simply, so making the distinction by means of the
document grammar seems unnecessary.  (An interesting challenge,
perhaps, but not part of the minimum required to declare victory.)

This leads to question 3:  Is the tool chain I am describing likely to
be of interest to any others in the TEI community?

If so, please let me know.  If you have specific suggestions,
requirements, or desiderata for such a tool chain, I'd like to know
those, too.  I don't expect TEI-L to be the best place for a
discussion of such requirements, but if I hear from anyone I will send
a summary of the results to the list, for future reference.

With thanks for the patience of any readers who have made it this far
into this mail,

Michael Sperberg-McQueen


[1] http://uyghur.ittc.ku.edu/atmo.html
[2] http://uyghur.ittc.ku.edu/manuscripts/index.xhtml#tr
[3] http://conferences.idealliance.org/extreme/html/2004/DeRose01/EML2004DeRose01.html
[4] http://conferences.idealliance.org/extreme/html/2006/SperbergMcQueen01/EML2006SperbergMcQueen01.html
[5] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#CORS5

********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
[hidden email]
http://www.blackmesatech.com
********************************************

Reply | Threaded
Open this post in threaded view
|

Re: Trojan Horse markup in TEI - three questions

C. M. Sperberg-McQueen
In reply to this post by bertrand Gaiffe-2
> On Oct 26, 2017, at 8:18 AM, bertrand.gaiffe <[hidden email]> wrote:
>
> There is a point I do not understand in your setting : elements of the secondary structure appear anywhere with respect to the first one, however, if the secondary structure is:
> <a><b>......</b>.....</a> do you accept that it translates as:
> <b sid.../><a sid..../>.........<b eid.../>......<a eid../> which is "somehow not wellformed”.

Excellent question.

You are quite right that the locations of elements in the secondary
structure are not completely arbitrary — certainly not with respect to
each other (and probably in some cases not arbitrary with respect
to the primary structure).  And a sufficiently expressive document
grammar might capture at least some of the rules and enforce them.

But in order to keep things simple, I am here following the example
of the SGML feature CONCUR, and my idea is essentially to validate
the relation between elements a and b and their tags only when the
document is in a form which puts a and b into the primary structure.
(Then validation is simple and straightforward.)  The translation into
Trojan Horse form which puts them into the second structure should
preserve their relative positions, because the transform which rewrites
a secondary structure as the primary structure will otherwise fail.

(This does mean that structural reorganizations of the document will
be very tricky — fortunately, that is not expected to be an issue in
the project I’m thinking about right now.)

>
> And, if not, do you accept <b sid/><a>..... <b eid/>... </a> with <a> from the primary structure ?

At the moment, I expect to accept such a sequence.  In work we did
some time ago, Claus Huitfeldt and I called examples like this
examples of “spurious overlap”.


—Michael

>
>
>
> Envoyé depuis mon appareil mobile Samsung.
>
> -------- Message d'origine --------
> De : "C. M. Sperberg-McQueen" <[hidden email]>
> Date : 25/10/2017 22:24 (GMT+01:00)
> À : [hidden email]
> Objet : Trojan Horse markup in TEI - three questions
>
> In connection with a project I am working on [1], I find myself with a
> few questions for which readers of this list may have useful answers.
>
> I apologize for the length of the message; I have tried to explain
> things that might not be universal knowledge, which takes space.  If
> you get lost in the thicket, a string search for 'question' will find
> the questions I am trying to pose.
>
>
> I Our particular flavor of the overlap problem
>
> The project is transcribing a number of unpublished manuscripts (as
> many as we have resources to transcribe) and providing linguistic
> annotation and English translations for some (as many as we have
> resources to annotate).  The curious reader can see some of our
> initial transcriptions at [2]; we do not currently have any published
> documents with translations and/or annotation.  (Partly because I
> haven't yet solved the problem I am describing here.)
>
> We would like to be able to view (and process) documents either (a) in
> the customized TEI built around sourceDoc, page, zone, and line which
> we are using for the initial transcription of manuscript), or (b) in a
> different customized TEI built around text, p, and s (for prose; text,
> lg, and l, for verse).  We would like to be able to convert documents
> between these two flavors of TEI without loss of information (so that
> as we find and fix errors or enrich the markup in either view, we can
> update the other view automatically).
>
> Since the page/zone/line structure of the one form and the
> text/paragraph/sentence structure of the other do not nest, we have
> the challenge of recording two structures in a single XML document.
> (We choose not to make it two separate documents in order to avoid
> synchronization issues.)  In our situation, unlike that in some
> projects, each of the two structures is easily realizable as a
> perfectly ordinary XML element structure; if we were using SGML, the
> CONCUR feature would cover our needs nicely.
>
> Question 1 When other projects have faced similar situations, what
> techniques have you used to organize the markup?  Do you have advice
> for us?
>
>
> II A tentative solution (Trojan Horse markup)
>
> The simplest general solution I know to this particular form of the
> overlap problem is the technique described by Steve DeRose in 2004
> under the name Trojan Horse markup [3].  This is a generalization both
> of the similar technique used by the Anglo-Saxonist David Megginson in
> the 1980s which I like to call "Megginson Grammars" (described in [4])
> and also in a different way a generalization of the TEI 'milestone'
> element [5].
>
> In Trojan Horse markup, some textual structures are represented by
> single XML elements in the conventional way; others (specifically
> those which don't nest within the element structure thus defined) are
> represented by two co-indexed empty XML elements, one representing the
> start of the textual structure and the other representing its end.
> Trojan Horse markup differs from Megginson grammars in providing
> explicit end-tags; it differs from the TEI 'milestone' element in not
> using a dedicated element type but instead using the same element type
> to represent conventional instances of a structure and the
> Trojan-Horse instances. In the following example adapted from [3], the
> 'sID' and 'eID' attributes on the 'q' elements identify the tags which
> bear them as Trojan Horse markup and co-index the start and end of
> each element.
>
>     <div>
>       <p>
>         <verse osisID="Jer.2.1">Moreover the word
>           of the LORD came to me, saying,</verse>
>         <verse osisID="Jer.2.2">
>           <q sID="Q-Jer.2.2-A"/>Go and cry in the
>           hearing of Jerusalem, saying,
>             <q sID="Q-Jer.2.2-B"/>Thus says the LORD:
>               <q sID="Q-Jer.2.2-C"/>I remember you,
>               The kindness of your youth, The love of your
>               betrothal, When you went after Me in the
>               wilderness, In a land not sown.
>         </verse>
>         <verse osisID="Jer.2.3">        
>               Israel [was] holiness
>               to the LORD, The firstfruits of His increase.  All
>               that devour him will offend; Disaster
>               will come upon them,<q eID="Q-Jer.2.2-C"/>
>             says the LORD. <q eID="Q-Jer.2.2-B"/>
>         </verse>
>         ...
>       </p>
>       <p>
>         ... <q eID="Q-Jer.2.2-A"/>
>       </p>
>       ...
>     </div>
>
> In a situation like ours where CONCUR would work fine, the co-indexing
> is strictly speaking redundant, but the co-indexing helps reassure me
> that my transformation has not messed anything up beyond repair.
>
> In order to use an element (like 'q' in the example) as a Trojan Horse
> tag, the schema needs to be doctored, so that
>
>   (a) Valid instances of the element can be empty.  (In the case of
>   elements present only in the secondary text structure, I'd want the
>   schema to require valid instances of the element to be empty.)
>
>   (b) Valid instances (ideally only empty ones) can carry either an
>   sID or an eID attribute.  Ideally, if eID is present all other
>   attributes will be invalid.
>
> In the use of Trojan Horse markup foreseen by Steve DeRose, the
> content models of potential parents need not be modified: Trojan Horse
> tags for the 'q' element should be valid wherever a normal 'q' would
> be valid, and nowhere else.  In our situation, however, the elements
> of the secondary document structure should not be constrained by the
> primary document structure, so their Trojan Horse milestone forms need
> to be legal more or less everywhere, which means that many or all of
> the content models for the primary document structure should be
> modified so that
>
>   (c) The Trojan Horse markup for any element in the secondary
>   document structure can validly appear at essentially any point in
>   the primary structure.
>
> (In this context, for the first time in twenty years or so, I miss
> SGML's inclusion exceptions; they would at least make it easy to allow
> the Trojan Horse markup for the secondary structure everywhere.)  In
> the ideal case, I'd like context-specific declarations for elements
> like 'p': in the document body, 'p' should be able to contain Trojan
> Horse markup for tei:zone (etc.), but not in the header.
>
> It seems self-evident that it is a subtle but essentially mechanical
> process to modify a schema to handle the sID and eID attributes, allow
> Trojan Horse elements to be empty, and allow Trojan Horse elements to
> appear pretty much everywhere.  Because it's subtle, I'd rather not do
> it by hand if I can avoid it.  Because it's mechanical, I think I can
> avoid it.
>
> Question 2:  do any readers of this list have (or know of) tools for
> this kind of operations on schemas or ODD documents?
>
>
> III Planning for the future
>
> Unless I am surprised by unexpected answers to questions 1 or 2 and
> led to change my plans, my current expectation is that I will develop
> the needed infrastructure in several stages.
>
> I'll probably start with a variant of Trojan Horse markup which
> requires no schema changes (because it places the start- and end-tags
> of the secondary structure into processing instructions or structured
> comments).  Using this variant, I'll:
>
>   1 Write a stylesheet to translate reduce the start- and end-tags of
>   the primary structure to Trojan Horse milestones, within some
>   context (here: within /TEI/sourceDoc and /TEI/text).
>
>   2 Write a stylesheet to identify the milestones for a given
>   secondary structure and make it the primary structure (accepting the
>   output of the first stylesheet as its input).
>
> The result can be thought of as a cheap XML version of CONCUR.
>
> I'll then move to Trojan Horse markup proper (or possibly to that uses
> a single element -- analogous to TEI 'milestone', but with a different
> design).  In addition to updating the two stylesheets mentioned above,
> this will require
>
>   3 A transformation to operate on a schema (better, an ODD document,
>   but that seems likely to be too challenging) to modify declarations
>   for specified elements, making them either (a) capable of appearing
>   validly either as 'normal' elements or as Trojan Horse milestones,
>   or (b) capable of appearing validly only as milestones.
>
>   4 A transformation to operate on a schema (again, better an ODD
>   document, if I could see how) to modify declarations for specified
>   elements, making allowing Trojan Horse milestones to appear anywhere
>   within them.  (The content-model modification technique to be used
>   here is the same as for the elimination of content-model inclusions
>   in the TEI after the development of XML; definitely automatable.)
>
> I do not expect at this time to attempt to automate a schema-level
> distinction between contexts in which Trojan Horse markup should be
> allowed and those in which it is not allowed.  A Schematron rule can
> do that fairly simply, so making the distinction by means of the
> document grammar seems unnecessary.  (An interesting challenge,
> perhaps, but not part of the minimum required to declare victory.)
>
> This leads to question 3:  Is the tool chain I am describing likely to
> be of interest to any others in the TEI community?
>
> If so, please let me know.  If you have specific suggestions,
> requirements, or desiderata for such a tool chain, I'd like to know
> those, too.  I don't expect TEI-L to be the best place for a
> discussion of such requirements, but if I hear from anyone I will send
> a summary of the results to the list, for future reference.
>
> With thanks for the patience of any readers who have made it this far
> into this mail,
>
> Michael Sperberg-McQueen
>
>
> [1] http://uyghur.ittc.ku.edu/atmo.html
> [2] http://uyghur.ittc.ku.edu/manuscripts/index.xhtml#tr
> [3] http://conferences.idealliance.org/extreme/html/2004/DeRose01/EML2004DeRose01.html
> [4] http://conferences.idealliance.org/extreme/html/2006/SperbergMcQueen01/EML2006SperbergMcQueen01.html
> [5] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#CORS5
>
> ********************************************
> C. M. Sperberg-McQueen
> Black Mesa Technologies LLC
> [hidden email]
> http://www.blackmesatech.com
> ********************************************

********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
[hidden email]
http://www.blackmesatech.com
********************************************