🚀 go-pugleaf

I had a brainstorm last night and thought I'd run it up the
flag pole.  It may be a hare-brained scheme, but who knows.

How about if we define a new grouping operator that contains
elements whose boundaries are independent of each other.
I'll use the delimiters '{' and '}' (left and right curly
braces) to delimit what I'll call "asynchronous groups" within
content model specifications.  The OR and AND connectors
have the same meaning they do normally, but the sequential
connector now defines the order that elements must be
*opened*, but not closed.  I'll also define the new sequential
connector ';' (semicolon), which defines the order elements
must be closed, but not opened.

If my analysis is correct, the parser would handle asynchronous
groups by maintaining independent state information for each
different element within the containing element.  It would
be up to the processing application to sort out the overlaps,
but the parser would provide sufficient information to
allow it to do that reliably.  The parser would still generate
the same messages for element start, element close, and
element data it does now, it just wouldn't require that
elements be completely containing.  It would probably be more
work for the application to sort out what's going on, but
it shouldn't be too much more difficult for the parser to parse.

Some illustrative examples:

Example 1, OR connector:

  <!ELEMENT container - - { x | y } -- contains X or Y         --
                                    -- X an Y are asynchronous -->

  Allows these instances:

  <container><x>xdata<y>xydata</x>ydata</y></container>
  <container><y>ydata<x>yxdata</y>xdata</x></container>

  As well as X contained by Y and Y contained by X.

Example 2, Comma sequential connector:

  <!ELEMENT container - - ( x, y }  -- X must start first --

  Allows:

  <container><x>xdata<y>xydata</x>ydata</y></></container>
  <container><x>xdata</x><y>ydata</y></container>

  But not:

  <container<y>ydata<x>yxdata</y>xdata</x></container>

Example 3, Semicolon sequential connector:

  <!ELEMENT container - - ( x; y }  -- X must end first --

  Allows:

  <container><x>xdata</x><y>ydata</y></container>
  <container><x>xdata<y>xydata</x>ydata</y></container>
  <container<y>ydata<x>yxdata</x>ydata</y></container>

  But not:

  <container><x>xdata<y>xydata</y>xdata</x></></container>
  <container><y>ydata<x>xydata</y>xdata</x></></container>

Validation of elements contained by asynchronous elements
is done against the most recently-opened element that
names the contained element in its content model.  For
example:

Example 4, Validation of contained elements:

  <ELEMENT (x | y)   - - (A)            -- X and Y contain A -->
  <ELEMENT container - - { x | y }      -- x and y asynchronous -->

  <container>
  <x><a>contained by x</a>
  <y><a>contained by y</a>
  </x><a>contained by y</a></y>
  </container>

  <ELEMENT x         - - (A)            -- contains A         -->
  <ELEMENT y         - - (B)            -- contains B         -->
  <ELEMENT container - - { x | y }      -- x and y asynchronous -->

  <container><!-- A and B valid in context -->
  <x><a>contained by x</a>
  <y><b>contained by y</b>
  </x><b>contained by y</a></y>
  </container>
  <container><!-- A and B invalid -->
  <x><b>out of context</a>
  <y><a>in context, contained by X</a>
  </x><a>out of context</a></y>
  </container>

I'm not sure any of this is sensical, but it seems to hold
together well enough to stand better analysis than I can
do.  My gut feeling is that there's some Achilles heel
that will show its head when things get more complex.

Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
Network Programs Information Development     Phone: 1-919-543-7091
IBM Corporation
Research Triangle Park, NC 27709