Re: Notes on the process

Bill Smith writes:
> I urge the ERB to reconsider this issue. At minimum, it is appropriate to
> see some acknowledgment that the ERB understands that it is limiting
> the use of XML to those applications that can abide by the draconian measures
> required by the proposed language. 

Note that Bill and I do not always see eye-to-eye on the various features
and positioning of XML, but certainly on error handling and several of Tim's
comments on the process, I agree with him. Yes, the contra-ERB traffic goes
up once announced in the WG because those who agree with the ERB have no
reason to voice their opinions except as responding to those who disagree
with the ERB and have made that disagreement known. There's no reason to
get off the train if it's going the way you want, right?

Of course, one may consider the opinion of those who disagree as noise,
that's your prerogative. 

<DIGRESSION SPAWNING-TOPIC="Error Handling">
The question has been asked before: are we trying to define the constraints
of an XML processor? An XML application? Either? Both? Neither? Shouldn't
we define and differentiate them better?

The processor should not be required to halt processing, but in certain
implementations the application should. This restriction, as Bill points
out, "precludes reasonable use of XML in certain applications." I don't 
know if I'd have created a car crash scenario, but I certainly can think
of others where _the_processor_ MUST continue. Do we actually have to 
create a loophole for non-conforming XML processors just so we can allow
for XML conformant applications? If the application can't tell what the
actual problem is, the processor continuing to parse and transmit to the
application 'for the correction of errors' is a potentially defensible
position under almost any circumstance, even in a browser, if that
browser is also used for authoring, the current model for Netscape
Navigator Gold. It's a big enough loophole to get a camel through.

I believe that if Microsoft and Netscape want a rigidly defined XML 
specification, that's what they'll get. But HTML is also rigidly defined.
Both the IETF and W3C specifications specify HTML as 'an application
conforming to the Internation Standard ISO 8879." While most HTML documents
are non-conformant, both Navigator and MSIE are demonstrably nonconformant
in accepting and displaying these documents irregardless of the level of
document error. They support the tags of the specifications, but not HTML
as an SGML markup language. We all prefer to call this 'being liberal in
what we accept', but it's simply a deliberate choice to ignore those parts
of the specification that don't fit with Web practice as defined by their
products. The result for some has been to propose that HTML no longer be
considered an SGML application, as it doesn't fit with current practice.

I can believe that both Netscape and Microsoft may want to avoid this same
situation as regards XML, but as has been pointed out before, the path to
this end is by way of quality, validating software applications; enforce-
ment doesn't occur in the specification. Where the specification doesn't
fit current practice (as defined and influenced by the MS/NS implementa-
tions), they will both ignore those parts of the spec that don't fit their
needs.

It's great to have a commitment on MS/NS's desire for rigid error handling
language, and I don't at all doubt Jean's word, but do you really expect
that commitment to hold up if it limited Microsoft's market with a commercial
product? Bill Gates would laugh and then move on. I don't know the people
at Netscape, but I suspect the same. This isn't any matter of fault or
blame; we all know the value *and* utility of standards. They are a target,
shaped by market reality.
</DIGRESSION>

Again, I think the notion mentioned by Henry of moving processor and
application conformance text to a separate document is a great idea and
worth of consideration by the ERB and the WG at large, or as Jon says,
the Working Group and the Interest Group.

Murray

...........................................................................
Murray Altheim, SGML Grease Monkey                    <altheim@eng.sun.com>
Member of Technical Staff, Tools Development & Support
Sun Microsystems, 2550 Garcia Ave., MS UMPK17-102, Menlo Park, CA 94043 USA
         "Give a monkey the tools and he'll build a typewriter."

Received on Thursday, 8 May 1997 20:16:56 UTC