Re: C.9 Forbid & connector?

At 11:46 10/18/96, Joe English wrote:
>David G. Durand <dgd@cs.bu.edu> wrote:
>
>> >C.9 Should XML forbid use of the '&' connector in content models
>> >(11.2.4.1)?
>>
>> Well, this is a peculiar reversal for me, but since we are going to keep
>> the weird semantics of SGML content models, & does not seem too burdensome.
>> And it is useful in some contexts. I don't feel strongly about it, but
>> we've already given up the hope that anyone can apply well known theory, or
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>?!?
>
>> common knowledge in implementing the feature, [...]
>> [...]
>>    Maybe that's an instance of another straw for the implementor's back,
>> but since we're throwing in a brick, I don't see that baking the brick with
>> straw in it is going to make that much difference.
>
>
>
>I don't recall seeing this resolution passed by the ERB,
>did I miss something :-)?   What "brick" are you talking about?

Way back when, Tim Bray posted the following, in the
"Report from the SGML ERB meeting of Oct. 9th":

>>A.27 XML will behave like SGML as regards behavior and precedence
>>of occurrence indicators and connectors in content models (11.2.4.1,
>>11.2.4.2).  (Whether to abolish the AND connector will be decided
>>separately.)

>Passed, Unanimous.

That means the whole ball of wax, to me. If I had to implement SGML's
ambiguity I'd implement and ambiguity check and match against the parse
tree for the model. If I'm parsing that way, what's a single bit of
additional state per moel token? As I say, I'm not emotional about kereping
&, just don't see why not.

>(The ambiguity restriction does not matter here: unambiguous content models
>are a strict subset of regular expressions; any algorithm for matching
>against general REs will also work for unambigous ones.  In fact,
>the ambiguity rule can make things *easier* for implementors.)
Yeah, once the check is over. It's doing the check that is unpleasant and
non-standard. Still, your point about hust using RE is a good one.

>> and & is easy when you just
>> parse against the parse tree (which is what people will do).
>
>I don't see that '&' is _easy_, but as long as we keep the
>ambiguity restriction it's at least tractable.

You just keep a flag as to whether the & group is used up yet or not.
Gross, but servicable and easy....

   -- David

RE delenda est.

_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________
http://www.dynamicdiagrams.com/services_map_main.html

Received on Friday, 18 October 1996 17:21:10 UTC