[tei-council] Notes from today;s conference call

[Syd Bauman]

Note: in the following I am using "or" to mean "inclusive or" and "or
... but not both" to mean "exclusive or", which is how I was taught
English in grade school.

> Under item 3, I think we not only discussed co-occurrence
> constraints, but also the possibility to instantiate certain
> attributes either as child elements or as attributes in a given
> schema (that was on the original list of features we wanted for
> P5). I would like to see this mentioned in the notes, so that we
> can reference it, if the need arises.

I'm not 100% sure, but I think they're the same thing. The ability to
express in a schema that something (say the "engineType" of
"automobile") is permitted as either an attribute or a child element
is, of course, trivial. The difficult part, that DTDs cannot do, is
to express that it is permitted as an attribute or a child element,
but not both. RelaxNG permits this with a construct that I believe is
called a "co-occurence constraint", but I'm not entirely sure that
this phrase isn't reserved for a specific case[1]. Thus:

  element automobile {
    attribute engineType { "int_combustion" | "hybrid" | "electric" },
    text
    }
  |
  element automobile {
      mixed {
        element engineType { text }
        }
      }

expresses this "either or, but not both" constraint. This is the kind
of thing I at least had in mind during the conference call.

Of course just

  element automobile {
    attribute engineType { "int_combustion" | "hybrid" | "electric" }?,
      mixed {
        element engineType { text }?
        }
      } [2]
    
with the prose "If engineType= is specified, then <engineType> must
not be a child; if engineType= is not specified, then one and only
one <engineType> child must be specified as a child" can be used to
express this constraint until we have a way to express it in ODDs.
(And furthermore, nifty Schematron constraints could be created to
enforce such things; sample below.)

Here are the test files I used when whipping up the above example. I
have also included the error message from two different open source
RelaxNG validators. I must admit, I don't understand the last error
message from xmllint.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: aet.rnc
Url: http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20040925/7895bd93/attachment.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: aet.errs
Url: http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20040925/7895bd93/attachment-0001.ksh 
-------------- next part --------------


Notes
-----
[1] I know that's what it's called when a 'value' pattern of one node
    is used to change the content of another. This is usually used to
    have different content models for the same element depending on
    the value of an attribute. See
    http://books.xmlschemata.org/relaxng/ch09s02.html.
[2] This is roughly the same as
      <!ELEMENT automobile ( #PCDATA | engineType )*>
      <!ATTLIST automobile
                engineType ( int_combustion | hybrid | electric ) #IMPLIED>
    except that the RelaxNG constrains the document to at most 1
    <engineType> child.