[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