Re: rationales for TEI extended-pointer keywords

James wrote, in reply to Michael's clear exposition:
> Thanks, you've mostly convinced me.

I think that's nearly very good indeed! :-)

[...]
>  PREVIOUS selects preceding sibling elements of the location source.
>  NEXT selects following sibling elements of the location source.
>  PRECEDING selects elements which appear before the location source.
>  FOLLOWING selects elements which appear after the location source.

[...]
> My concrete suggestion would be to drop the terms PRECEDING/FOLLOWING since
> SDQL and TEI give them opposite meanings and use PREVIOUS/NEXT/AFTER/BEFORE.

I don't think this is any clearer -- without an explanation, I would have
no idea at all that AFTER meant only elements after this one in the same
container, and that NEXT meant the next element in the input, or the
next sibling, or whatever.

I think the right answer is to be specific:
    NEXT -- the element whose opening tag occurs next in the input after
	the current element's end tag
    NEXT SIBLING -- NEXT restricted to the current container
    PREVIOUS -- the element whose opening tag occurs most recently
	in the input
    PREVIOUS SIBLING -- the element whose close tag is immediately 
	followed by the current element's opening tag.
    
I can also imagine extending this to include
    expr1 IN expr2
where expr1 and expr2 are TEI extended pointer expressions, to mean
expr1 provided that it occurs within the content of expr2, and an
error otherwise.

I am not proposing this feature, as I don't think it addes enough it
practice, except that it seems to me to be the generalisation of
TEI's PREVIOUS and NEXT.

> - 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?
Well, what about the case where it could be any of a number of elements?
For example, I want to link to the first bibliographic citation
in a note element that's inside a PART, but the note could occur either
in a chapter, a section, an appendix or a procudure...

> 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.
I don't see that -- if you have typed data structures, can't you use
those for untyped links too and ignore the type?

> - 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.
I agree about IMPLIED.  I think the other two are useful.
The second is easiest to find examples for: find the first <person> with
any value for the ROLE attribute.  I am not sure you can also find the
first <person> _without_ a ROLE attribute unless you have *IMPLIED.

* for an attribute name is just as useful as * for an element type.

I can't answer your question on case folding, since I think that
case insensitivity is a bad idea anyway, and all comparisons should be
case sensitive!

Lee

Received on Wednesday, 11 June 1997 18:18:54 UTC