[tei-council] Fwd: please post to tei-council list

Laurent Romary Laurent.Romary at loria.fr
Sun Apr 11 13:47:34 EDT 2010



Début du message réexpédié :

> De : Syd Bauman <Syd_Bauman at Brown.edu>
> Date : 11 avril 2010 14:49:20 GMT+02:00
> À : Laurent Romary <Laurent.Romary at loria.fr>
> Objet : please post to tei-council list
> Répondre à : Syd_Bauman at Brown.edu
>
> Re: <relatedItem> constraints
>
>
> Dear TEI Council --
>
> I discovered at our recent seminar that the constraints for
> <relatedItem> were internally inconsistent, and did not match the
> prose.
>
> The RELAX NG constraint said target= was optional, and a single child
> element was required. The prose said that if target= was present, in
> general a child would not be. The Schematron check stated that if
> both were present, it was an error, but the XPath test did not
> actually check for child elements, but text() node descendants. (If
> the child element is empty, then there may be no text() node
> descendants; thus the formal check really said "if target= is present
> then only an empty child element is allowed", thus missing target=
> and <ptr> or an accidentally empty <bibl>.)
>
> So I have checked in a new version that "fixes" some of these
> problems, but opens a can of worms.
>
> Fixed corrigible errors:
> * added <listRef>
> * changed <content> so that a child element is optional in RELAX NG
>  constraint
>
> Consequent fixes:
> * added a Schematron rule to check that either target= or a child
>  element is present
> * changed remarks to make it clear that both target= and a child
>  element are not allowed
>
> Questionable fix:
> * altered existing Schematron rule to check for existence of child
>  elements, rather than text() descendant.
>
> Problems for Council to consider:
>
> 1) Should both target= and a child element be allowed? I am pretty
>   sure that ala SF FR 2728061[1], only one or the other should be
>   present.
>
>   Personally, I agree with the conclusion in the ticket, that the
>   answer should be 'no': <relatedItem> should have *either* a
>   target= or a child element, but not both.
>
> 2) IF the answer to (1) is "no", THEN Council also needs to consider
>   whether or not <ptr> is allowed inside <relatedItem> at all. I.e.,
>   whether it makes sense to allow both
>      <relatedItem target="#a"/>
>   and
>      <relatedItem>
>        <ptr target="#a"/>
>      </relatedItem>
>   Note that if the answer to (1) is "yes", then <ptr> needs to be
>   allowed as content, in order to say
>      <relatedItem target="#one"/>
>        <ptr target="#two"/>
>      </relatedItem>
>   which is why I really think the answer to (1) should be "no" :-)
>   See below for my opinion on (2) itself.
>
> 3) Note that if the answer to (2) is "no, <ptr> is not allowed as a
>   child of <relatedItem>, use target= instead", then cRef= needs to
>   be added to <relatedItem>, too. This is a pain, and thus another
>   reason to answer (2) as "yes" (although not a good one :-).
>
> 4) Should <relatedItem> be allowed to be empty? I.e., should
>     <relatedItem/>
>   be valid?
>   I think it should not be valid, as it is meaningless.
>
>
> below)
>   I think that <ptr> should be allowed as a child of <relatedItem>,
>   so that one can use parallel constructs for pointers to related
>   items whether I happen to want to auto-generate the content or
>   not. I.e., I think users should be allowed to have
>          <relatedItem type="whatever">
>            <ptr target="#A"/>
>          </relatedItem>
>          <relatedItem type="whatever">
>            <ptr target="#B"/>
>          </relatedItem>
>          <relatedItem type="whatever">
>            <ref target="#C">untitled article by unknown author</ref>
>          </relatedItem>
>          <relatedItem type="whatever">
>            <ptr target="#D"/>
>          </relatedItem>
>   when they want to auto-generate the references to A, B, and D, but
>   hand-generate the reference to C. Furthermore, users may wish to
>   use other attributes on <ptr> (most obviously type=).
>
>
> BTW, this problem wouldn't be nearly so complicated if target= hadn't
> been added to <relatedItem>. I think that was a sizable mistake. It
> added quite a bit of complication to save ~20-25 characters worth of
> extra markup. Which, using oXygen's fancy completion, only takes a
> few extra keystrokes to get inserted.
>
> P.S. In researching this I found reference to a suggested value list
>     for type= of <relatedItem> invented by PS. I think having a
>     semi-open list of suggested values for type= of <relatedItem> is
>     really important. This is a confusing issue, and many users will
>     have the exact same needs, may as well be using the same values.
>
> Notes
> -----
> [1] https://sourceforge.net/tracker/?func=detail&atid=644065&aid=2728061&group_id=106328

Laurent Romary
INRIA & HUB-IDSL
laurent.romary at inria.fr





More information about the tei-council mailing list