extended pointers for P4
Lou Burnard
lou at ermine.ox.ac.uk
Mon Feb 18 05:13:45 EST 2002
On Sun, 17 Feb 2002, John Unsworth wrote:
> >It does break existing documents, but as they will be broken anyway because
> >the tag names will become case sensitive, I think it is the least evil
> >choice.
>
> but I'm not sure that existing documents would be broken by the possibility
> of case-sensitivity in an XML version of the TEI DTD, whereas it seems to
> me they would be broken by a requirement of case sensitivity in the SGML
> version of the TEI DTD. If that assessment is off, I have no doubt someone
> will let me know.
<p>There already *is* a requirement for case-sensitivity in the keywords
of the extended pointer syntax e.g. you must say "ID (foo)" not "id (foo)"
and "ANCESTOR (p 1)" not "ancestor (p 1)", even though "ANCESTOR (P 1)"
would be OK, since the GI "p" is *not* case sensitive in SGML! This
inconsistency is so close to nonsense that I think it verges on the
corrigible error. Especially because making the syntax case insensitive
throughout wouldn't break existing valid documents. It might unbreak some,
of course, and if we ever decided to revert the decision or go the way
suggested by Comissar Rahtz, it might give us with a legacy data problem
in the future.
<p>>
> > > On the issue of whitespace should we
> > >
> > > a) make no changes, leave the whitespace required;
> > > b) make the whitespace between location types and location values,
> > > and between parenthesized steps, optional.
> >
> >how about c), make white space disallowed?
> >
> >I sort of incline to a), you might be surprised to hear.
> >Just so as to keep the number of variables as small as possible.
>
> On the same principle, I think b), above, is less likely to break things.
>
Same principles apply, I think. We currently have a restriction which we
can choose to relax, or not.
L
More information about the tei-council
mailing list