Re: proposals for new XML

[Karl Berry]

Hi Patrice,

    1. Some things that break compatibility 

Sure, we've already given up on XML compatibility on the theory that the
new form will be more useful.

    but seems not questionable to me:

I agree with that (section 1).

    Have only <image> and no <inlineimage>.

Doesn't that make it harder, if not impossible, for the XML-processor to
figure out how to output the image, something you already know (don't
you?)?  How about <image where="inline"> or something?

    Use <pre> for preformatted portions of text, and use the
    xml:space="preserve" on <pre>, for example

There are no special rules about <pre> that would get in the way?  E.g.,
that it can't contain other environments?  I believe there are in HTML
.. that is, I seem to recall HTML documents not validating because of
stuff inside <pre>.

    rename, for @itemize the argument <itemfunction> -> <itemprepend>

See below.

    rename <title> for sectioning @-commands as <sectiontitle>
    let @settitle and @title -> <settitle> and <title>

Ok, those seem logical.

    For @itemize, add a <prepend> element, so for example

Looks sensible to me in general.

    <itemize commandarg="&minus;"><itemprepend>&minus;</itemprepend>

So we're specifying the arg to @itemize as both an attribute and an
element?  Why?

    <item><prepend>&minus;</prepend><para>in item

Is there a reason to use an element instead of an attribute?
Somehow it seems more conventional to use an attribute here.  But
whatever.

    For table I propose an element called itemformat with the command in 
    attribute. For example

Ok in general.

    <tableitem><tableterm command="item"> ...

Why <tableitem><tableterm command="item"> here,
but simply <item> for @itemize?

And, when @itemx is used, where does the x show up in these cases?
Just trying to understand ...

Thanks,
k