The SRU Editorial Board has revised the MARC Context Set proposal and has
withdrawn the substring proposal.
The substring modifier is now part of the MARC context set (rather than the
The revised proposal is at:
The reasoning is as follows.
The discussion on substring extended way beyond those interested in the marc
set, but led to the conclusion that a general substring function was not
only superfluous (a regular expression modifier had already been planned for
addition to the cql set) but also difficult to reach consensus on and
probably not worth further effort.
On the other hand, the simple substring capability (simple, without the
esoteric and more complex features added) has been identified as a
requirement for the marc set (but not as a general requirement). Regexp is
complex and might not be widely implemented. Someone contemplating
implementing the marc set will be more likely to do so if it can be done by
implement substring rather than regexp. In fact not much at all of substring
would need to be implemented. One could claim for example support for the
index 'marc.008=/marc.substring="0:6' without claiming general substring
As there has been much controversial list discussion over the substring
proposal, it seems to the Ed. Board that the most expedient thing to do is
define substring, not in the cql set, but in the marc context set. In the
future, one of the following might happen:
(a) People might want substring elevated to the cql set.
(b) People implementing the marc set might decide to use regexp instead of
(c) People implementing the marc set will implement substring and nobody
So if (a) happens, we can elevate substring. If (b) happens we can
depricate substring. If (c) happens we're fine.
Please comment on the MARC Context Set proposal by September 15.