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

I agree with Paul P. and Charles on A28.

I actually do believe it's possible and worthwhile to make a DTD for 
markup model specifications because of the benefits of managing the 
specs and, to a smaller degree, writing them, but this isn't a 
self-evident characteristic of the language.  (FOSIs are SGML 
documents, which may not have been the most natural syntax choice 
in the world, but they do automatically get the benefits of SGML 
information creation, storage, and management.)

However, I don't think we're the right agency to do this.  I had 
earlier felt that this should be a WG8 project, but Paul's analysis 
of the market solutions pointed out that the "invisible hand" agency 
is appropriate too.

I have no problem issuing an "advisory" or "informational" DTD for 
DTDs (along with the appropriate transformers) as a side project, 
whenever we get around to it -- we've certainly got the right talent
lying around!  And I think there's nothing wrong with seemingly 
having two notations for DTDs (which would go against our principle 
of having one way to do things); this should be in the realm of a 
helper application.  If it's popular enough, it can later be nailed
down as a standard.

If XML is popular, more people will start writing DTDs, and to the
extent that the technology is brought down to the individual-contributor
level, the proportion of DTDs to instances will probably go up.  
However, for the kinds of DTDs that will contribute most to the
increase at first, syntax won't be the big barrier.  This just isn't
a five-alarm problem.

        Eve

At 05:33 PM 10/7/96 -0400, Paul Prescod wrote:
>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 19:42:28 UTC