The Power of ODD

Remember how ODD stands for One Document Does it all? You can derive a number of different schema and documentation output formats from the single ODD file you’re editing! The Download button at the top right of the Roma screen lets you choose between 3 types of output: ODD files schema files, in a number of flavours documentation files, in a number of output formats

Since these are frequent operations when customising TEI, they are treated in separate sections below.

What Does a Minimal TEI Customisation Tell Us?

Before proceeding, let’s have a closer look at what we’ve done. As mentioned before, the TBEcustom.odd file we had stored earlier, is just a TEI XML file. Let’s have a look what’s inside!

The TBE crew TEI Consortium Distributed under a Creative Commons Attribution-ShareAlike 3.0 Unported License

Created from scratch by James Cummings, but looking at previous tei_minimal and tei_bare exemplars by SPQR and LR.

A Minimal TEI Customization

This TEI ODD defines a TEI customization that is as minimal as possible and the schema generated from it will validate a document that is minimally valid against the TEI scheme. It includes only the ten required elements: teiHeader from the header module to store required metadata fileDesc from the header module to record information about this file titleStmt from the header module to record information about the title publicationStmt from the header module to detail how it is published sourceDesc from the header module to record where it is from p from the core module for use in the header and the body title from the core module for use in the titleStmt TEI from the textstructure module because what is a TEI file without that? text from the textstructure module to hold some text body from the textstructure module as a place to put that text

A minimal TEI customisation ODD (download)

One immediate observation is that an ODD file is indeed just a regular TEI document, with a TEI root element, containing a teiHeader element and a text element. Remember the metadata you entered in the Settings tab in Roma, and see how it is reflected at the proper places inside the teiHeader. However, the most interesting bits are inside the body part.

Apart from regular body content, as illustrated by the p contents of our minimal TEI customisation, an ODD file contains a specific schemaSpec element. This element indicates a formal definition of a TEI schema. It has a mandatory ident attribute, supplying an identification code for the schema. The language of the documentation can be specified with an optional docLang attribute; when necessary a targetLang attribute can specify what language to use for element and attribute names. The prefix attribute specifies the prefix that will be added to the names of TEI patterns in the customisation. The start attribute identifies the root element(s) of the customisation: in this case, it will produce a schema that only allows the TEI element as root element for valid TEI documents.

Since an ODD file is just a regular TEI file, the formal schema specification in schemaSpec can be completed with a detailed prose documentation (and in fact, the concept of an ODD file is intended to contain both formal specifications and prose documentation), using the regular TEI elements in the body part. Our current example only contains very minimalistic prose documentation; for an excellent example, see the documentation in the TEI Lite ODD file, and compare it with the different documentation files offered at .

The schemaSpec element is the core of any ODD file, specifying the formal definition of a TEI schema. A TEI customisation can be constructed by referring to definitions of existing TEI objects (element and attribute classes, datatypes, and macros), or—as will be covered later in this tutorial—by declaring new objects as well. In our example so far, the schema specification only contains references to four of the predefined TEI modules. Each module is being referred to in a separate moduleRef element, whose key attribute is pointing to the formal identifier of that module in the TEI source.

When a module is selected with moduleRef in an ODD file, by default all elements and attributes of that module are incorporated in the customisation. In our example, this is the case with the tei module. As we have seen, this is a special module, which doesn’t define any elements and attributes itself, but instead a lot of classes, datatypes, and macros that are being used in all other TEI modules. Three of those other modules are being referenced in our current ODD file. Yet, only a very small number of elements they define are being included in our customisation, because the moduleRef elements have an include attribute, where only those elements that should be included are enumerated as a white-space separated list. If you count them, our customisation only selects the 10 elements that are required for minimally valid TEI documents.

Notice, how the include mechanism has a counterpart: it is equally possible to specify which elements not to include in a module by enumerating them in an except attribute. This will only exclude those elements, but will include all others. Both mechanisms offer convenient shortcuts to either include or exclude large numbers of elements. It’s important to remember that you can only use either the include or the except attribute on a moduleRef element, but not both.

TEI groups its different elements and their attributes in 21 modules. When defining a TEI customisation, these modules can be referred to in an ODD file. An ODD file is just a regular TEI document with a specific element for defining a TEI schema: schemaSpec. An identification for the schema must be provided in an ident attribute. Inside the schema specification, modules can be referenced with a moduleRef element, naming the module in a key attribute. When a TEI module is included in a customisation, by default all of its elements and attributes will be included. In order to include specific elements only, the names of these elements can be enumerated in an include attribute. Likewise, if only some of the elements of a module should be excluded, they can be enumerated in an except attribute on moduleRef.

Inspecting a Customisation in Roma

As we have introduced in , the TEI is a highly sophisticated library, holding model and attribute classes, macros, and datatypes. Customising TEI requires some knowledge of how they are organised. Full documentation can be found in the TEI Guidelines, but fortunately, Roma is conceived as a convenient online store for selecting the exact TEI components you need, and doing so, it shows you around in the internals of TEI as well. Let’s start editing our current customisation where we have left it by hitting the Customize ODD button at the top right in the Roma screen:

Start customising an ODD file with the Customize ODD button.

This will take you to the main Roma dashboard. You can tell you’re editing the right customisation from the title at the top of the screen, which reads Roma - ODD Customization (A TBE customisation).

Roma main screen.

Below the title, you see 4 different tabs at the top of the screen: Elements: an overview of all available TEI elements, allowing you to select and customise those you need Attribute Classes: an overview of all available TEI attribute classes, allowing you to select and customise those you need Model Classes: an overview of all available TEI model class definitions, allowing you to select and customise those you need Datatypes: an overview of all available TEI datatype definitions, allowing you to select and customise those you need

Let’s check how the moduleRef elements we’ve seen in our current TEI customisation are being reflected in the Roma interface. When you select the Elements tab, you’ll notice that only a very small number of elements are ticked. Indeed, from the long list of available TEI elements, only 10 have been selected: body, fileDesc, p, publicationStmt, sourceDesc, TEI, teiHeader, text, title, and titleStmt. Notice, how the default ordering in Roma is alphabetical; you can also click the by module button at the top right of the Roma screen. This will order the elements (or attribute classes, or model classes, or datatypes) alphabetically: first per module, and next by name. This sorting by module gives you an idea of what TEI components are being defined in each of the modules. This is broader than elements: if you look at the other tabs, you’ll notice that a lot of attribute classes, model classes, and datatypes are being included automatically when a TEI module is included via moduleRef in a TEI customisation.

Selecting Modules and Elements

In order to encode the textual phenomena we’d identified for our example text, a number of TEI elements have to be included in our TEI customisation. This can be done easily in Roma by ticking the corresponding boxes in the Elements tab.

The Elements tab in Roma.

Notice how the right-hand column in Roma informs you for any element which module it belongs to. A convenient way to include or exclude all elements from a module at once, is by selecting or de-selecting that module. In order to do so, you can click the module name. For example, let’s select the figures module by clicking the plus sign next to that module name:

If we order the elements by module (by clicking the by module button at the top right of the Roma screen) and scroll down to the figures module, you’ll see that all of its elements now have been included in your customisation. This includes some elements we didn’t identify in the document analysis for our document; if we are absolutely certain we only have to encode images, but no tables, formulas, or music notations, these elements can quickly be deselected by unticking the element name in the left-hand column:

De/selecting elements in Roma.

Did you notice how the graphic element is part of the core module, and not of figures? If you want to include the images themselves in your transcription of , you’ll have to include the graphic element as well. Hint: you can quickly look up an element by entering its name in the search box at the top right of the Roma screen:

Filtering element names in Roma.

That’s all there is to including and excluding existing TEI elements with Roma! You can also remove an entire module at once, with the caveat that this will remove all its members (and possible modifications you’ve made to them) from your customisation. Since you might run the risk of losing work here, Roma issues a warning in order to prevent unwanted mistakes:

Warning when removing an entire module in Roma.

Now, save your customisation as an ODD file (click the Download > Customization as ODD button at the top right of the Roma screen). Its schemaSpec element will be updated to:

A minimal TEI customisation with more TEI elements added (download).

Because all further changes to the ODD file in this TBE tutorial module will affect only its schemaSpec part, the example fragments will focus on this element.

When we generate a TEI schema from this customisation (via the Download button at the top right of the Roma screen), this allows us to validate a transcription of a typical page of the document (the third image from the scans above) as follows:

So far for selecting modules and elements. The obvious counterpart, adding new elements, will be dealt with later in this tutorial (see ). First we will focus on attributes.

Modules can be selected simply by referencing them with a moduleRef element, whose key attribute must be used to identify the desired TEI module. By default, all elements of a module are selected for inclusion in the schema. If an include attribute is present, only those elements that are being enumerated will be included in the customisation, and all others won’t. If you want to exclude only a couple of elements from a module, but include all others, this can conveniently be done by enumerating the ones you don’t want in an except attribute. You can’t use both at the same time.

Changing Attributes

Adding Elements

So far, our TBEcustom customisation includes a generic name element (from the core module) for identifying names in our encoding project. Apart from this generic element, TEI defines a set of more specialised elements for encoding names, in the namesdates module. These elements add more semantic detail and leave more room for further (sub)typing. Let’s use Roma to have a look at what namesdates has to offer: load the TBEcustom customisation again in Roma if you haven’t done so already, and click the Customize ODD button, in the Elements tab, click the by module button at the top right of the Roma screen and scroll down to the elements of the namesdates class.

Grouping all elements of a TEI module in Roma.

In this long list of specific elements for names and dates, two look particularly interesting for our purposes: persName (as an alternative for name type="person") and placeName (as an alternative for name type="place"). Let’s include them in our customisation: tick the boxes in Roma, and store the ODD file via the Download > Customization as ODD button at the top right of the Roma screen. As you probably have expected, this will add following instruction to the ODD file:

If we generated a schema of the TBEcustom customisation at this point, we would be able to rephrase the encoding of the different names in our fragment as follows: Alice Lobster Gryphon Mock Turtle

Of course, this dual approach to name encoding, with the specialised persName and placeName elements for person and place names respectively, and the general name element with type=animal for animals, is undesirable. Therefore, we’ll extend our TEI customisation with a dedicated element for encoding animal names. As before, the remainder of this section first outlines the necessary steps in Roma, and next discusses the resulting ODD file.

In Roma, new components (elements, classes, datatypes) can be added to a TEI customisation by clicking the NEW button at the bottom right of the screen:

The NEW menu for adding new TEI components in Roma.

We’ll be creating a new element for animal names, so click the Element button of the pop-up menu. This opens a form with three fields. Let’s fill them: Name: the name of the element. By analogy to persName and placeName, let’s make this animalName Module: the TEI module this new element will belong to. Since this is a specialised naming element, let’s select namesdates. Namespace: the namespace of the (non-TEI) element. As we’ve mentioned before, let’s make this http://teibyexample.org/ns/TBE

Create new element form in Roma.

After clicking the Create button, our new element is born! If an ODD file is generated at this point, it would be expanded with following instructions: This tells that our customisation defines a new element animalName in the http://teibyexample.org/ns/TBE namespace, which will be made available in the namesdates module.

Yet, with empty classes and attList children, this element definition is still utterly useless. We have to define a number of essential properties: the attribute classes this new element belongs to the model classes this new element belongs to the content of this new element

Exhaustive reference information for the TEI class system can be found in the TEI Guidelines, Appendix A: Model Classes and Appendix B: Attribute Classes. Datatypes definitions can be accessed from Appendix E: Datatypes and Other Macros. For an in-depth prose description of the entire TEI infrastructure, see chapter 1 The TEI Infrastructure of the TEI Guidelines.

These are important decisions to make, which require conscious thought, as well as an understanding of the TEI class system. Fortunately, we can learn by example: since we are modelling a new element for animal names to the existing persName TEI element, we can use the declaration of the latter as a source of inspiration, or just plainly copy it. Let’s have a look at the definition page for persName: load the TBEcustom customisation again in Roma if you haven’t done so already, and click the Customize ODD button, move to the Elements tab and scroll down to the definition of persName.

The Documentation button shows the description for the persName element.

Display of the documentation for the persName element in Roma.

The Attributes button shows us the attribute classes. If only the top-level attribute classes are considered, that aren’t defined inside other attribute classes, (the others are being included automatically when their superclass is included), this list can be reduced to: att.datable: groups attributes for normalisation of names or dates att.editLike: groups attributes for describing the nature of an encoded interpretation att.global: groups common attributes for all TEI elements att.personal: groups common attributes for names att.typed: groups attributes that allow (sub)classification of an element

Display of the attributes for the persName element in Roma.

The Class Membership & Content Model button shows us the model classes of which persName is a member: model.nameLike.agent: groups elements which contain names of individuals or corporate bodies model.persStateLike: groups elements describing changeable characteristics of a person which have a definite duration, for example occupation, residence, or name This means that persName, and all other members of these model classes, can occur wherever TEI elements specify their contents in terms of these classes.

Display of the class membership for the persName element in Roma.

The content model of the persName element is represented graphically in Roma. It refers to the macro.phraseSeq macro, which represents a predefined sequence of character data and phrase-level elements. This means that persName can contain text intermixed with a whole range of sub-paragraph level elements (abbr, expan, name, persName, ...).

Let’s copy these same declarations to our new element. Return to the Elements tab and click the animalName element. In the description box, we can enter a prose description for the animalName element, for example:

Editing the documentation for the animalName element in Roma.

Clicking the button labeled animalName < on top left of the Roma screen, gets us back to the overview of the animalName definition. A click on the Attributes button shows us that its attribute list is empty, as we saw already in the generated ODD file. In order to declare its membership of the 5 attribute classes we had identified in the definition of persName, start by clicking the plus sign in the Attribute from Classes row. Next, filter or scroll through the list of attribute classes, and click the plus sign next to the ones we want to add.

Adding the animalName element to attribute classes in Roma.

Finally, return to the overview of the animalName definition, and click the Class Membership & Content Model button. In order to define how our animalName element will behave, click the plus sign in the Model Classes row and select the 2 model classes we had identified by clicking the plus sign next to their name.

Editing the class membership of the animalName element in Roma.

Next, its content can be defined by first clicking one of the Groups, References, or Nodes blocks. This will produce an overlay menu, with a graphical indication of the different types of ODD constructs that can be used for selecting individual nodes or combining them in groups, or referencing one of the predefined TEI macros or classes. We’ll be inserting a reference to the macro.phraseSeq macro, so we’ll click the References block.

Selecting a macro for the content model of the animalName element in Roma.

We want to include a reference to a macro, so macroRef is the block we’ll want to add. This is done by dragging that block into the graphical editor screen of Roma. Next, clicking the arrow in that macroRef block calls a dialog window where the macro.phraseSeq macro can be selected via the plus sign next to it. Finally, make sure to drag this populated macroRef block into the empty space of the blue content block in the graphical editor (you’ll hear a little click sound if it succeeds):

Adding a macro to the content model of the animalName element in Roma.

Now it’s time to inspect our ODD customization: store the ODD file via the Download > Customization as ODD button at the top right of the Roma screen. The resulting ODD file looks as follows:

used for place names used for person names used for animal names contains a proper noun referring to an animal ODD definition of a new (non-TEI) element (download).

We see how an extra elementSpec element is added to the ODD file, with the definition for our newly added animalName element. Its name is given in the ident attribute, and mode=add indicates that this is a new element. The ns attribute contains the namespace URI we specified for this element.

The description of our brand new animalName element is provided in a desc element. Its class membership is declared in a classes element; each of the attribute and model classes we had selected, is listed in a separate memberOf element, whose key attribute identifies the relevant class. The content of the element is declared within a content element. Since we included the shortcut to the macro.phraseSeq macro, this is recorded in a macroRef element, whose key attribute identifies the macro.

In order to give an impression of the convenience of macros, let’s see what this macro.phraseSeq macro resolves to when the ODD file is being processed:

We’ll not go into full details here, but you’ll be able to understand that this macro defines a sequence with zero (minOccurs=0) or more (maxOccurs=unbounded) combinations of plain text nodes (textNode), or the elements from the 4 model classes identified in classRef. For full coverage of the definition of content models: see section 22.5.1.1 Defining Content Models: TEI of the TEI Guidelines.

Elements can be added to the existing TEI model by declaring them with an elementSpec element, with the value add for its mode attribute. The ident attribute must give the name of the element. Specific to added elements is the use of the ns attribute, whose value should provide a unique namespace URI for this element, different from the default TEI namespace (http://www.tei-c.org/ns/1.0). A prose description of the element can be given in a desc element. The structural behaviour and attributes of an element are defined in the classes element, containing memberOf declarations for each model or attribute class to which the element is added, identified with the key attribute. The content of the element is declared in the content element, containing either references to TEI macros, or hand-crafted sequences of nodes, elements, or element classes.

Adding Attributes

So far, we have customised our schema for the transcription of the text in such a way that we can distinguish between person, place, and animal names, either with specific type values of the generic name element (namely person, place, or animal), or by means of the TEI elements persName and placeName, and the non-TEI element animalName. We fine-tuned all elements belonging to the att.naming class by deleting the unneeded nymRef attribute from this class.

For our specific analysis of we would like to experiment with a basic way of adding further information on the ontological status of the referents of the names in this fictitious story: it could be interesting to analyse the characters in terms of the kind of reality they exist in. A possible place for such information could be the type and subtype attributes of the att.typed class. However, we would prefer a more specific label for this kind of information, and reserve these TEI attributes for possible different categorisations in the future. Therefore, we want to add a new attribute to our customisation. Similar to deleting attributes, adding new ones can happen on two levels: element level: attributes may be added to an individual element, which will apply to this element only → This is accessible in Roma via the Attributes button in an element’s definition (via the Elements tab), where you can click the plus sign in the Element attributes row. In ODD, it will affect the attribute definition inside an elementSpec element. class level: attributes may be added to an attribute class, which will apply to all elements that are member of this class → This is accessible in Roma from the attribute class’s definition (via the Attribute Classes tab), where you can click the desired class name, click the Attributes button, and add additional attributes to the class. In ODD, it will affect the attribute definition inside a classSpec element.

In this case, information on the ontological status of names’ referents not only applies to personal and place names, but also to our recently added animal names, names in general, and by extension all kinds of referring strings. This suggests the att.naming attribute class as a good place to add this attribute.

Let’s head over to Roma! Click the Attribute Classes tab for our TEI customisation, click the att.naming class, and next hit the Attributes button.

Editing an attribute class for a TEI customisation in Roma.

This calls an overview of the attributes in this class (notice how the nymRef attribute still is excluded from our modification). Adding a new attribute to an attribute class can be done by clicking the plus sign in the Class attributes row. This produces a dialog window:

Creating a new attribute in Roma.

This form asks us first for the name of this new attribute. Before we start defining the attribute, some thought is needed on its design. Following examples could illustrate different possibilities: Alice Mock Turtle Gryphon

Attributes could be designed as binary choices taking some form of truth value, as categories taking some kind of degrees on a scale, as neutral labels taking a list of keywords, or many more. As we are in the early stages of the encoding project, and feel this ontological classification is still experimental, we can anticipate that categories are likely to pop up, merge, or be adapted along the way. Therefore, it makes most sense to design it as a general semantic field, allowing for an open-ended list of keywords. Considering these requirements, a sensible name for this attribute could be ontStatus. Let’s fill that name, and click the Create button. Now, this (empty) attribute definition is added to the list of Class attributes. In order to define this attribute, click the pencil icon next to its name. This will produce a page similar to the one we’ve seen before (when restricting the values of the type attribute for name). We’ll define this ontStatus attribute as an optional attribute, by selecting this in the dropdown box next to Usage. In the Description field, we can provide a description, such as: describes the ontological status of a name’s referent

Editing documentation for a new attribute in Roma.

The other fields define the actual content of the attribute. For this example, suppose that an initial (experimental) categorisation for the ontological status of the people, places and animals in the story could look like this: realistic: the referent can / could occur in the extra-textual reality mythological: the referent does not exist in real life, but belongs to a major mythology fantastic: the referent belongs to an idiosyncratic fantasy universe However, it is prone to be extended with other categories, and would probably allow more categories to be applied simultaneously, for names referring to ambiguous creatures or places.

This analysis obviously translates into a semi-open list: choose that option for the Values field. Attribute lists in ODD can have three types: closed only the values defined in valList are permitted semi the values defined in valList are treated as suggested values, but others are allowed open any value is allowed (as long as it complies with the datatype); values in valList are treated as mere examples

Suggested values can be entered in the text field of the Values field, and next pressing the plus sign next to the value. Let’s add the values mentioned above, as well as their description.

Defining attribute values for a new attribute in Roma.

Finally, the datatype for the attribute’s value can be declared in the Datatype field. The TEI datatype teidata.enumerated, which is explicitly designed to define a single word from a list of possibilities, seems the best fit.

Defining the datatype for a new attribute in Roma.

In the introduction to this section we stated that extending the TEI always leads to TEI document models that are broader than and hence possibly incompatible with the standard TEI model. For maximal separation of extension features from the standard TEI model, the TEI Guidelines therefore advice to define extensions in their own namespace. We already did so when adding new elements in the previous section. Let’s declare the same namespace http://teibyexample.org/ns/TBE in the Namespace field for our ontStatus attribute:

Defining a namespace for a new attribute in Roma.

To save these changes as an ODD file, click the Download > Customization as ODD button at the top right of the Roma screen. We’ll notice how a defintition of the new ontStatus attribute now is added to the classSpec declaration for the att.naming attribute class:

describes the ontological status of a name's referent the referent can / could occur in the extra-textual reality the referent does not exist in real life, but belongs to a major mythology the referent can / could occur in the extra-textual reality ODD definition of a new (non-TEI) attribute in an attribute class (download).

Since we added the ontStatus attribute to the att.naming attribute class, the corresponding attDef declaration is added to the list of attribute declarations of the corresponding classSpec element. As before, the class specification’s mode attribute is set to change, indicating that only the declarations present in this ODD file will update the existing TEI definitions. Inside the attList section, the nymRef attribute still is deleted, in accordance with our previous changes.

However, there’s a new attDef element for our ontStatus attribute (identified in the ident attribute), this time with the value change for its mode attribute (since there was no existing definition for this element, this has the same effect as mode=add). The opt value for the usage attribute indicates that the ontStatus attribute will be optional in our customisation (required attributes would have req).

Inside the attribute definition, the desc element contains the prose description of the attribute. The datatype of the attribute is defined in datatype. By means of a dataRef element, it is referring to the existing TEI datatype definition teidata.enumerated (which is given as the value for its key attribute). This datatype basically restricts the possible values to strings consisting of words or a limited range of punctuation marks. Combined with the declarations in maxOccurs, this means that the ontStatus attribute for animalName can contain a white space separated list of word characters and some punctuation marks.

This introductory tutorial doesn’t cover the advanced inner mechanisms of TEI in full; for more information you can read section 1.4.2 Datatype Specifications of the TEI Guidelines, or the reference section in Appendix E: Datatypes and Other Macros.

Finally, the list of possible values is given inside valList, which is declared as a semi-open list. Each of these values is given in its own valItem element, with a description of that value in desc.

Adding attributes is done within an attDef declaration inside the attList declaration, either in the definition of a single element (elementSpec) or an attribute class (classSpec). The addition is specified in the add value for the mode attribute of the attribute definition; the name of the attribute is given in the ident attribute. Additionally, attDef specifies the usage of the attribute within usage (opt for optional attributes, req for mandatory ones). In order to distinguish added attributes from standard TEI ones, it is highly recommended to declare a dedicated namespace in the ns attribute. An attribute definition typically contains a prose description in desc, an indication of the attribute’s datatype in datatype (referring to one or more of the predefined TEI datatypes), and a list of possible values in valList. Such lists may be specified as closed, semi, or closed in the type attribute. Each predefined attribute value is declared in the ident attribute of a separate valItem element.

Other Types of Extension

Besides these common cases of TEI extension, involving the addition and deletion of elements and attributes, TEI can be extended in both more subtle and complex ways: existing TEI elements can be renamed content models of existing TEI elements can be broadened datatypes and occurrence indicators of attributes can be broadened existing TEI elements can be redefined to different model classes

Most of these types of customisations make use of the mechanisms covered in this tutorial. However, these kinds of modifications are considered advanced topics and are not treated in this introductory tutorial. For more information, you are referred to chapters 22. Documentation Elements and 23. Using the TEI of the TEI Guidelines.

The lobster sugaring its hair.

"How the creatures order one about, and make one repeat lessons!" thought Alice, "I might just as well be at school at once." However, she got up, and began to repeat it, but her head was so full of the , that she hardly knew what she was saying, and the words came very queer indeed:—

"'Tis the voice of the lobster; I heard him declare, 'You have baked me too brown, I must sugar my hair.' As a duck with its eyelids, so he with his nose Trims his belt and his buttons, and turns out his toes."

"That's different from what I used to say when I was a child," said the Gryphon.

"Well, I never heard it before," said the Mock Turtle; "but it sounds uncommon nonsense."

Alice said nothing; she had sat down with her face in her hands, wondering if anything would ever happen in a natural way again.

"I should like to have it explained," said the Mock Turtle.

"She can't explain it," said the Gryphon hastily. "Go on with the next verse."

"But about his toes?" the Mock Turtle persisted. "How could he turn them out with his nose, you know?"

"It's the first position in dancing." Alice said; but she was dreadfully puzzled by the whole thing, and longed to change the subject.

"Go on with the next verse," the Gryphon repeated impatiently: "it begins 'I passed by his garden.'"

Alice did not dare to disobey, though she felt sure it would all come wrong, and she went on in a trembling voice:—