Re: rationales for TEI extended-pointer keywords

At 09:16 AM 06/11/97 +0700, James Clark wrote:
>This is my major concern about having both PRECEDING/FOLLOWING and
>NEXT/PREVIOUS. It's going to be very hard for people to remember.  This is
>especially the case since the TEI meanings for PRECEDING/FOLLOWING are the
>opposite of the SDQL meanings:

Yikes! How did we all let that happen. Never mind. I kind of like the names
LSIBLING and RSIBLING for the ones that do that. Or, to accommodate other
writing directions, E(lder)SIBLING and Y(ounger)SIBNLING; or N(ext)SIBLING
and P(revious)SIBLING to match the others. I find the terms James proposed
an improvement, but I think it would be even clearer with "SIBLING"
blatently in the name (this may be especially true for ESL speakers who may
lack sprachgefuhl for the subtleties of other terms. Thus I like Lee's
suggestion except for the embedded blanks in the keywords, which would
require tweaking some BNF.

>- Why do we need to allow * for the element type name?  Why can't we simply
>require that all steps include the element type name or *CDATA?  This
>eliminates the confusion over whether * counts pseudo-elements or not.   It
>makes my life harder as an implementor to have to support both typed and
>untyped counts: making typed and untyped counting efficient requires
>different data structures.

Interesting. TEI strongly recommends using a type, but we didn't feel we
could require it. If the users are willing, I'm fine with that.

>
>- Why do we need * for the attribute name?
>
>- Why do we need * for the attribute value?
>
>- Why do we need *IMPLIED for the attribute value?  This is only going to
>work in the presence of the DTD.

These are largely for symmetry and completeness. If all the parameters don't
look as alike as possible, there's more to explan. I doubt people actually
use * for attr name or value. I see James' point re. optimization being
harder if you have to go cache counts of attribute values, etc.

>>As far as I can see, there's no way to ask for example for the first
>>element in the document with attribute FOO equal to BAR.  DESCENDANTS
>>doesn't do it, because it will not work when the document element is
>>the first such element.  I think we need another keyword which is like
>>DESCENDANTS except that it includes the location source.  This is the
>>subtree function in SDQL.  I would suggest either TREE or SUBTREE as
>>the keyword.

Interesting case. If we make such a change, I should think we'd want it
symmetrically: all keywords would be able to count themselves as a
possibility. The most important case is probably ANCESTOR; I've had
customers who want to refer to the nearest containing element of type X,
whether or not it's where i started. DynaText scripting thus added a
nearest() function for that, as distinct from ancestor() which it already
had but which could never return the element itself. This could be
accomplished by doubling the number of keywords (yech) or adding a parameter
or parameter value.

steve

Received on Thursday, 12 June 1997 15:23:21 UTC