Re: A28: syntax of markup declarations? (LONG)

At 01:27 PM 10/7/96 -0700, Jon Bosak wrote:
>(Speaking only for myself)
>
>I have thought about Tim Bray's proposal to use the same syntax for
>instances and markup declarations and find that I am in complete
>agreement.
>
>1. It makes no sense to claim that we have created a syntax suitable
>for the markup of structured data in general and then not use it for
>the markup of the structured document that defines a particular
>schema.  From a marketing standpoint this is indefensible; from a
>logical standpoint it is absurd.  I have heard no one deny this.

I do! I do! :)

You can stretch the definition of "structured document" to include whatever
you want, but I think that users have common sense, and will recognize that
there are limits to that which a particular document can do. The first few
words of Annex A of the SGML standard are "Text processing and word
processing". The definition of "markup" in ISO 8879 is 

"markup: text that is added to the data of a document in order to convey
information about it." (if I'm reading the S.H. right),

Without the markup in your DSD, there _is no data_. 

In practice, there is nothing at all wrong with encoding non-textual
information in SGML for consistency, standardization, too reuse, etc. but I
don't think that anyone should feel compelled to encode non-textual data in
SGML. We don't need to standardize a DTD (or DSD) for GIFs or JPEGs to prove
that we believe in SGML. 

Why doesn't DSSSL look like this:

<define name="*sans-serif-font*">Helvetica</define>

<define name="*rgb-color-space*">
   <color-space>ISO/IEC 10179:1996//Color-Space Family::Device RGB"</>
</define>

Note that a DSSSL script _is_ "wrapped" in an SGML document. If we wanted to
do that with traditional SGML DTDs, I would be much less critical, but many
of the benefits would be lost.


Furthermore, I don't think that anyone other than SGML purists would even
consider using a markup language for encoding documents without text-data.
They would certainly not think us odd for not doing so. After all, the
people we are talking about don't see anything wrong with mixing JavaScript,
VBScript and HTML into one document.

Perhaps in the fullness of time, SGML2000 should go the opposite way: it
should provide simple mechanisms for changing markup syntaxes that would
allow us to specify a "DTD for DTDs" and a "DTD for scheme programs" without
expanding DTD and scheme program instances into the verbose-existant SGML
instance syntax. It isn't right to unify all languages under the SGML
"banner" by making them harder to read and longer to download.

In short, I think we can be consistent philosophically without using
instance syntax for DTD syntax, by using the "the right tools for the right
jobs" argument. 

>2. I am not qualified to certify the correctness of the proposed DSD
>syntax, but I can guarantee that it would be no harder to teach than
>the current DTD syntax, and I strongly suspect that it would be
>easier.

To teach, yes. To use? I'm not sure.

>3. Unlike many other features -- marked sections, for example -- that
>we can defer for the moment if we wish and introduce in a later
>version of XML, this is not something that can wait.  We have to take
>this approach from the beginning or it will never happen.

Why can't it happen later? Standards change. Sometimes new standards are
built on top of them.

>If there are flaws in the DSD syntax included in the November
>draft, then early implementors will soon expose them, but if it's not
>in that draft, we're stuck with an illogical and indefensible failure
>to employ the very philosophy that we are espousing.

I don't think that it is a departure from our philosophy for the reason I
described above. A DTD isn't a text document, any more than an MPEG is, and
I don't feel guilty in the least telling clients that SGML doesn't wash
dishes. I don't want to start a chain of anecdotal contradictions, but I've
never had a newbie ask me why DTDs aren't SGML documents (though they may
have wondered why the syntax was so different...I don't know).

Once again, I find the idea attractive, but I have doubts. DTDs are "on the
line" of documents that should be SGML-encoded. There are standardization
benefits if they are, but efficiency benefits if they are not. I like the
IETF philosophy: "when in doubt, leave it out." I fear that if we veer from
that, we'll make a mistake that will cost us in the long run.

"The market" has had the opportunity to implement this idea, just as Tim
described it, with DTD->DSD translators. Near and Far, Fred and DTDtoHTML
could have an "output SGML Instance" option, but don't. If DSDs are useful,
I think that we should prove so in the marketplace of ideas and tools. I am
more than willing to "play around" with DSD, DSD converters and DSD-based
manipulation tools in the next few months, to see if they solve actual
problems that I have.

But in the meantime, I think that we may be solving a non-problem (or minor
problem). XML isn't the place for that. I would argue (again) that we should
defer this decision by leaving structural validity testing out of the XML
standard. That's what SGML is for.

 Paul Prescod

Received on Monday, 7 October 1996 17:39:37 UTC