Re: XML and required DTDs

> Date:         Fri, 13 Sep 96 14:12:46 CDT
> From: Michael Sperberg-McQueen <U35395@UICVM.CC.UIC.EDU>

I'm having a hard time figuring out for myself the links from my posting
to Michael's response (though I know they must be there, since what he says
usually does make a lot of sense to me).  I suspect we're working with
differs sets of prior text here, and I haven't made the leap yet.

First, I'm assuming for the purposes of this conversation that, by "DTD," 
we mean any logical equivalent thereof.  So content models and attribute
list declarations and such in any form is, for this discussion, logically
a "DTD."  Also, I'm not worried about significant white space issues, but
I am concerned about valid element/attribute names and content models.

I don't understand how Michael's four choices relate to my thoughts.  Forget
choice (d) [we seem to agree there].  Either DTDs are always required or 
they're optional--forget about what for, since if they're optional, there
will be times I don't have them, and that's the situation I'm addressing.

> 
> a DTDs Required for Parsing.

> 
> b DTDs Required for Validation
> 
> Declarations are always required, but the language is so constructed
> that the document can at least be parsed correctly* without reading the
> DTD.r declarations need not always be read.  I.e. it's possible to do
> some kinds of useful work even without reading all the declarations.

Understood, if by "some kinds of useful work" you mean, for example,
viewing, and you are specifically not including authoring/creation/editing.

> 
> c DTDs Optional
> 
> Declarations are always allowed, but not always required; the system
> makes certain default assumptions if no declarations are provided.

Are you including editing systems when you say "the system?"  From your
later comment (the last para of your message I include below), I assume
so.  More on that below.

> 
> d DTDs Forbidden

> 
> Cover, Grosso, and Bullard seem to be arguing against (d), but I'm not
> sure whom they are arguing against.  My own reading of the goals
> document is that (b) or (c) should apply -- or at least, that (a) is not
> what's wanted here.  I don't think anyone is actually in favor of (d),
> and if the current phrasing of the goals statement gives readers that
> impression, then it needs to change.  Can someone who finds the current
> phrasing confusing suggest a less confusing alternative?

No, I'm not arguing against (d)--I don't even know what it means to
"forbid [the existence of] a DTD" since we've said in the discussion
that one can/might auto-generate some DTD given an instance.  I think
I'm mostly addressing (c).  And, as I said explicitly in my message,
I'm not sure what I'm arguing for or against yet.

>  Note that choosing (c) is not the same
> as saying validating editors are impossible, as Paul Grosso seems to
> suggest --

I am suggesting (and I think you're agreeing in your next paragraph)
that validating editors are impossible when--in the context of 
choice (c)--someone exercises the option of not providing a DTD.

> any more than C compilers can't do syntax checking, just
> because variables can be declared implicitly.

Sorry, I'm missing the analogy.

> 
> A validating editor just doesn't belong to the class of applications for
> which declarations are inessential.  When presented with an XML document
> which has no DTD, it might (a) warn about missing declarations, (b)
> silently assume <!ELEMENT foo - - ANY>, or (c) something else entirely.

I am confused with the distinction between a DTD being optional and
and not having a DTD.  For me, there is very little difference.  If
it's optional, there will be times that the option for it not to exist
(or, at least, not to have the same accessibility as the instance itself)
will be exercised [I think that's the definition of optional].  

In other words, I'll have the instance and not the DTD.  Now, what is
an (XML or SGML) editor supposed to do?

I assume an SGML editor will have to generate/intuit some DTD to
which the instance conforms, and then it can happily use that to
edit the document.  Fine.

Now what about an XML Editor?   Do we envision such a thing as an 
XML Editor that works without declarations?

If so, then we're at the same place I got to in my previous post:  "an
XML content provider or editor can create new elements/attributes on
the fly and insert them however they wish in the document (with about
the only constraint being that the basic synchronicity of element
hierarchy be maintained)?"

Tim's post said, "I, and I think most people involved in this, absolutely 
definitely do envision having the equivalent of an SGML Markup Declaration."

But how is that statement reconciled with choice (c) that makes the
declarations optional?  If the declarations are optional, certainly
we'll have the creation of tools that try to edit XML without declarations.

Is this a good thing?  (I don't know--maybe, in some circumstances.)  I
was asking if this was a design goal.  I don't know how to interpret
either Michael's or Tim's response.  I need some more help here from
those more familiar with the ERB discussions.

paul

Received on Friday, 13 September 1996 19:16:56 UTC