Re: 2.1 a-d: Link Recognition by Reserved Attribute?

On Fri, 21 Feb 1997 17:17:15 -0600 Len Bullard said:
>Michael Sperberg-McQueen wrote:
>> I think this discussion is beginning to show signs [of
>> misunderstandings] ...
>
>Glad to know some of us read minds better than others.

If the shoe fits, wear it.

I was trying to help clarify vocabulary for two parties who seemed on
the verge of starting a flame war by systematically misinterpreting
each others' messages.  I don't read minds.  But I do read the postings,
possibly with more understanding for where David is coming from than
you've exhibited, and possibly with more understanding of where you're
coming from than David may have gleaned.  If you'd rather have a flame
war than a useful exchange of views, suit yourself.  (And hand me that
torch.)

>> If I understand Len and others aright, they worry that some people
>> would like to conceal any relationship between XML Link and HyTime.
>> This would be problematic for several reasons, among them the fact
>> that some potential users will be worried if HyTime is *not*
>> invoked, and (in some ways more important) it seems more honest to
>> acknowledge our intellectual debts where we can.
>
>There is no worry of that.

If what I described is not what you're worried about, then I have
misunderstood your earlier postings completely, and my attempt at
mediation was ill founded.  Sorry to have wasted everyone's time.

>> I believe there are certainly potential users for whom the mention
>> of HyTime will cause fear, trembling, and a mad rush for the exit ...

>Fear is still fear.  It is a bad way to reason.  If some are caught
>in that fear, it is their own problem to be considered.

If we hope to persuade an audience of something, then their fear,
reasonable or not, is not their problem but our problem.

>However, the normative reference is more than an acknowledgement
>of intellectual parentage.  It is the authoritative reference
>for the boundaries of the development of the subset being
>adopted by XML.  If it is not, and 8879 and 10744 are
>not boundaries, then XML is not the basis for SGML Lite and
>a competitor to XML will be developed.

Fear is a bad way to reason, Len.  You told us that a moment ago;
you don't need to add a demonstration of it here.

It's WG8, not you, who will decide what to put into a revised 8879.  I
know enough of its members that I am confident that they are capable of
noticing that XML guarantees the SGML conformance of valid XML
documents, and of valuing the increased accessibility SGML gains by
having clear documentation of a useful subset.  You insult their
intelligence by suggesting otherwise.

>> In drafting the original XML language spec, we worked very hard to
>> ensure that no *normative* reference to 8879 was necessary.
>
>That is a mistake.  Conformance to SGML is one of the most
>important features of XML.  If that is not understood by now,
>then the ERB should resign en masse and let WG8 do this.

Conformance to SGML was *accomplished* in XML.  If you have not
understood that by now, who should be resigning?  It was not
accomplished by reference; it was accomplished by hard work.  It
does not need to be guaranteed by a normative reference; it is
guaranteed by the restrictions explicitly made in the XML spec.

>> I claim that there *is* no normative reference to 8879
>> in the XML spec.  The conformance of XML documents to 8879 follows as
>> a logical consequence of the constraints given in the spec; it does not
>> rely on a rule formulated as "You have to do whatever 8879 says you do."
>
>They don't.  We do.  Conformance with SGML, that is, that XML is a
>wholly comforming subset of SGML is the primary constraint.  That
>is why a TC has been offered by WG8's chair.  That is not a light
>matter.  If such conformance is abandoned, the chair of WG8 should
>reconsider that offer, and WG8 should continue with a separate
>and competing version.  It will be ISO, authoritative, and something
>which those whose contracting agreements span nations and considerable
>investment will be made aware of.  It will be XML that dies; not SGML.

Len, if you ever see signs of XML abandoning the principle of
SGML conformance, then perhaps remarks like this paragraph will be
in order.  Until you do, they are wildly off the mark.

The point at issue is not whether XML documents are legal SGML; the
point is how that result is accomplished and documented.  You seem to
wish we had accomplished it by providing a document that could not be
understood without reference to 8879; I think it is good that we did
produce a document that is comprehensible by itself.  Since there are
*already* SGML subsets designed for easy implementation which take the
approach you seem to prefer, I suppose we can let the market decide.  So
far, after three months we have two publicly available XML parsers and
an indeterminate number not yet public.  After eleven years, how many
publicly available Minimal SGML parsers do we have?  Seems to me the
market has already decided.

>> I believe David and some others are mostly arguing that we need to
>> take the same approach with XML Link.  It will *not* be a good idea
>> to say something like
>>
>>   "XML Link uses HyTime-style architectural forms as defined in
>>   the Extended Facilities Annex.  See that document for notation
>>   and meaning of architectural forms."
>
>If they wish to understand the full and authoritative definition of
>AFs, that is precisely what it should say.

Yes, of course.  If any reader wishes to understand the full definition
of anything, going to the place where it is defined is usually a good
idea.  Why someone interested in the full definition of architectural
forms would be looking for a treatment of them in the XML Link spec is
beyond me.  But let's suppose they are reading the XML Link spec in the
hopes of understanding not HyTime, and not SGML, and not CALS, and not
the historical development of the Sanskrit passive, but -- for some
reason -- XML Link itself.  Why not allow them to understand the
full and definitive account of XML Link by making that account complete
and self-contained?

The XML Link spec needs to provide a full definition of XML links; that
includes the aspects of architectural forms used by XML Link.  It should
*not* delegate that task to 10744.

> > There are two reasons this would be a bad idea.  (1) We want people
>to
>> be able to understand XML Link by reading just the XML Link spec;
>> any requirements, notation, and semantics we take over from HyTime
>> should be documented fully in the XML Link doc.
>
>You gave up your credibility there, Michael.  You nor your group has
>the authority to take over anything.  That is exactly the problem
>with this work.  ...

I don't know whom you mean by 'my group', but any group defining a
formal system has, as far as I can tell, the right to adopt concepts
from other systems.  That's one way intellectual endeavors make
progress:  adopting good ideas from predecessor systems.

The W3C SGML WG and ERB, in defining XML Link, have both the authority
and the responsibility to take over useful concepts from wherever we
find them.  I don't know why my mention of this obvious fact offends
you, or why you claim we don't have authority to define XML Link in
whatever way we choose, for good or ill.

>                 As for having to read ISO 10744 or ISO 8879, they only
>have to do that if the XML subset is incomplete with respect to
>a developer's requirements.  OTW, why would they read that?

We seem to differ in opinion here.  Whether it's necessary to read 8879
and 10744 seems to me *not* a question of whether the *subset* is
complete or incomplete, but a question of how complete the documentation
of the subset is.  Normative references are, as I understand the term, a
sign that the documentation before the reader is itself not complete.
Informative references are an entirely different matter.

>>  (2) HyTime AFs
>> have a lot of machinery XML Link will probably not use.  There is no
>> need to refer your visitors to a map of the U.S. when all they want to
>> know is where the guest bedroom is.
>
>If my visitor wishes to leave a guest bedroom and go to another
>state, that map is of use.  If all they wish to do is sleep in
>the bedroom, why would one offer them that?  It is a facile

Good question.  Perhaps you will answer the corresponding question
about XML Link.  If all the reader wishes to do is to understand
how XML Link works, why would you and others insist that instead
of explaining in the spec how XML Link works, we say instead "First,
you must understand ISO 10744; then come back and you'll be able to
understand the rest of this spec."

>comparison and misses the point:  ISO is authoritative.  XML
>is a set of recommendations from a consortium working group.
>That is it's EXACT authoritative status.  Don't confuse these issues.

I don't believe I have confused them; I don't believe I've tried to
discuss them at all.  I don't believe they are relevant to this
discussion, which centers on the question of whether XML documentation
should itself contain full descriptions of salient constructs or
should rely for those descriptions on other documentation such as
ISO 10744 or ISO 8879.  The specification for XML itself does not
rely on 8879 in the way you now seem to require; why did you not mention
this requirement when we were discussing that draft?

>> We know from experience that if you define a simple subset of a
>> complex standard by saying "Well, use this standard, but turn off the
>> following features," the simple subset might as well not exist.
>> For example:  minimal SGML and basic SGML.  No one can understand
>> either one without understanding pretty much all of 8879.
>
>That is not the case.

Can you name anyone who has understood 8879's definition of Basic
or Minimal SGML without understanding the rest of 8879 first?

I have been told the point of Basic and Minimal SGML was to simplify
the task of creating low-end SGML systems.  OK, where are those
systems?

>                       Whatever experience you have, you have
>not learned the lessons it provides.  If you work in the
>industrial side of the SGML community, you know that the
>authoritative references are the ones that can be quoted
>in contracts.  That is one reason why ISO HTML is greeted
>with relief.

It's always interesting to read about strange and unfamiliar customs
and beliefs.  Thank you.  I feel like I'm reading an ethnological
report.

By the way, though, if industrial concerns are unable to do things
without authoritative references to ISO standards, why are so many
industrial concerns (a) on the Web, using HTML, and (b) using
the internet at all, given that the TCP/IP family of protocols is
so hopelessly incompatible with the relevant ISO standards?

Since valid XML documents are by definition valid SGML documents,
however, there is nothing to prevent the inclusion of references to ISO
8879 in a contract for an XML system.  Why would there be?

>> ... normative
>> references are for cases where you don't want to have to explain
>> everything the reader needs to know.  That should be avoided as far
>> as humanly possible in all three of the XML-family specs.
>
>No:  they are the authoritative chain of references which enable
>contractual obligations of all parties.  If you and your committee
>members cannot live with that, resign now.  Otherwise, be aware
>of your obligations to your community.

If you mean we have an obligation to our community to make the XML spec
incomprehensible and impenetrable, I respectfully and forcefully demur.

-C. M. Sperberg-McQueen
 University of Illinois at Chicago

Received on Friday, 21 February 1997 20:20:00 UTC