Re: 4.5 TEI Extended Pointer Locators?
In message <email@example.com> Tim Bray writes:
> 4.5.a Should we support these?
> 4.5.b What portions of TEI extended
> pointers should be dropped from this spec?
None at all. I have very specific and important uses for all of these,
especially TOKEN, SPACE and FOREIGN. These are particularly important for
non-textual applications such as numeric data.
I make use of constructs such as:
<ARRAY>1.2 2.3 3.4</ARRAY>
extremely frequently and so do most other people in technical fields.
(The alternatives like:
waste space and are less human readable. I can't operate without
subaddressing into this sort of construct. Admittedly the example
above can be tackled with SPACE, but I am sure there are some that can't.
[BTW. what are the default delimiters for tokens? can they be changed?
And I am mystified by the example in A.1.1.13 (the 3rd, 4th 5th tokens
in "This is _not_ a very good idea" are apparently:
"not_", "a" "very"
The _ acts as a delimiter if it leads a token but not if it trails it?
(Any default use of _ as a delimiter will cause scientists a lot of
grief, I suspect).]
We have many uses for multidimensional data. While large data sets
may be best managed by NOTATIONs (e.g. NETCDF) there are many places where
arrays are easily and cheaply passed and need subaddressing.
This is essential. My understanding is that I can use TEI navigation
to locate (say) the fifth MOL with a child of BIB and then to apply my own
method for searching that subtree (in this particular case a molecular
search, using (say) Java classes). This will also be vital for numeric
data - find all matrices and return those which are positive definite is
a reasonable request.
This isn't in the spec, but if it signifies applying a regexp to the
#PCDATA content of the node I will argue strongly for it.
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences