Re: producing the draft of XML Datatype spec

Paul-- Thanks for the comments and the compliments!  Here's a quick
response to your requests for DTD enhancements.  I'll probably wait for a
few weeks to collect comments from all the new editors, and then do another
revision.

At 10:18 AM 4/1/99 -0800, Biron,Paul V wrote:
...
>So far I've only found one minor thing that I'd change and a few small pet
>peeves.  As to the pet peeves, I think the content model of things like list
>items should be mixed and the DTD requires paragraph-type block structures,
>i.e., the DTD requires
>
>
>	<ulist>
>		<item><p>this is an item</p></item>
>		<item><p>this item has <emph>emphasized</emph>
>text</p></item>
>	</ulist>
>
>whereas I'd rather do
>
>	<ulist>
>		<item>this is an item</item>
>		<item>this item has <emph>emphasized</emph> text</item>
>	</ulist>
>
>Its not really a big deal, but it is a personal pet peeve (see below).

This is probably not going to get changed.  The current structure allows
you to have highly structured list items (such as a paragraph, a code
listing, and another paragraph).  Putting everything in a big mixed content
bag would allow mixtures of paragraphs with raw #PCDATA, or alternatively
would allow only a single paragraph-like blob for every item.

If you begin using the ADEPT environment, the <p> tags will become pretty
transparent and (e.g.) get inserted automatically when you begin typing.

>The thing I would change, however, is the content model of the editorial
>note element (actually, the edtext sub-element of ednote).  Currently, it
>allows only #PCDATA, with the rationale
>
>	The content of edtext need not be more complicated than #PCDATA
>because the note doesn't need to contribute to the "real" content of the
>document.
>
>We've found that it is useful to include sub-elemenets in edtext such as
>various reference or link types, lists, etc.

For me, this is a good enough rationale for expanding the content model!

>Also, we've introduced a "usage convention" for the optional date and name
>sub-elements of ednote which goes against the stated description of ednote
>("The ednote element identifies commentary passed between editors and
>authors of a document.").  In particular, we've used "signed" ednotes for
>communication between and "unsigned" ednotes for communication between the
>editors and the WG.  We'll see if the distinction is useful.

I'll keep an eye on this, and see if the model needs updating and/or the
semantics need tightening up over time.

	Eve

Received on Friday, 2 April 1999 12:12:38 UTC