Possible pattern versus non-pattern example

[Patrick Durusau <patrick@durusau.net>]

Greetings!

I have one possible example of the use of a pattern versus a non-pattern 
for values.

Consider the following:

<define name="cellAddress">
    <data type="string">
        <param name="pattern">($?([^\. ']+|'[^']+'))?\.$?[A-Z]+$?[0-9]+</param>
    </data>
</define>

<define name="cellRangeAddress">
    <data type="string">
        <param name="pattern">($?([^\. ']+|'[^']+'))?\.$?[A-Z]+$?[0-9]+(:($?([^\. ']+|'[^']+'))?\.$?[A-Z]+$?[0-9]+)?</param>
    </data>
</define>

<define name="cellRangeAddressList">
    <!-- Value is a space separated list of "cellRangeAddress" patterns -->
    <data type="string"/> 
</define>

I am waiting for a reply on this example but to be quite honest, I don't 
think cellRangeAddressList is adequately defined from the standpoint of 
XML validation.

It really should be specified as a space delimited list, however 
allowing for a list to consist of a single cellRangeAddress (in which 
case there would be no trailing space).

 From memory:

((($?([^\. ']+|'[^']+'))?\.$?[A-Z]+$?[0-9]+(:($?([^\. ']+|'[^']+'))?\.$?[A-Z]+$?[0-9]+)?)\s)+


Note that I am uncertain about the added syntax. Is a 
cellRangeAddressList always more than one cellRangeAddress or is it 
possible to have a list with only one item?

Whether this and similar values triggered the comment or not remains to 
be seen.

But, in any event, I will isolate all of the examples of this particular 
practice as it is something that should be fixed in ODF 1.2. There may 
be a pattern to using <data type="string"/> when what is mean is a space 
delimited list of some sort.

In other words, there may be other cases where patterns were not used 
consistently so I don't want to focus too narrowly on this example at 
the expense of not uncovering other inconsistent use of patterns.

This should not affect backwards compatibility since any application 
actually using cellAddressRangeList would have to implement the 
equivalent of the regex (or something close thereto) in order to have 
this sort of list.

Hope everyone is at the start of a great week!

Patrick

PS: In the current specification, see 8.3.1 Referencing Table Cells for 
the material quoted herein.

-- 
Patrick Durusau
Patrick@Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work!