Re: minutes

[Norman Walsh <nwalsh@arbortext.com>]

/ Michael Sabrio <rms@fpk.hp.com> was heard to say:
| I don't think the comparison with 4.0//EN//XML will help.  What I'd like,
| I guess, is 4.0//EN//XML with 4.0//EN//SGML, but that's what's hard.

I'm not sure I understand. You're going to get a 4.0//EN (you
have beta1 now :-) and you're going to get a 4.0//EN//XML.

I thought it would be helpful to try validating a bunch of your
documents against 4.0//EN//XML as a way of seeing how bad 5.0 is
going to be.  Does that not make sense?

| How would you describe where IndexTerms can no longer appear? 

Broadly, outside of *Info elements in places where #PCDATA is
not allowed. But that's too broad a net, I've actually added
them in a bunch of places. Basically, run your docs through
4.0//EN//XML and let me know where they should be added :-)

| Here are
| the kinds of places I'd expect IndexTerms to be invalid in 5.0: between
| chapters, between sections.

Really?

<chapter>...</chapter>
<indexterm>...</indexterm>
<chapter>...</chapter>

Where is that indexterm? On the last page of the first chapter!?

| What about inside Titles? 

Yes. Anywhere that #PCDATA occurs.

| between start tag
| and Title?  immediately following section Title before next start tag?

That's the ugly case I alluded to. As Eve pointed out, it could
be done, but I haven't yet felt motivated to do it. There's some
advantage, I think, in keeping the content models as simple as
practical.

| Where would you put the IndexTerms to include a reference to an entire
| chapter?

Assuming I wasn't using Zone? I guess I'd put the StartRef before the
first para and the EndRef after the last para.

| Is it possible to summarize where they _will_ be allowed --
| "inside a block-level thingy below the section level"?  (This is speaking
| formally, of course.)

Not very formally.  Informally: anywhere that #PCDATA can occur
and in selected other places where the addition of optional
indexterms did not cause ambiguity problems or make the content
model overly complex.

It's a significant backwards compatibility issue and I think we
should do everything we can to minimize it.

                                        Cheers,
                                          norm

-- 
Norman Walsh <nwalsh@arbortext.com> | DNA neither cares nor knows. DNA
Principal Software Engineer         | just is. And we dance to its
Arbortext, Inc. (www.arbortext.com) | music.--Richard Dawkins
413.256.6985 Voice/FAX              |