interoperability in the face of extensibility

On today's call, Steven expressed (if I understood him correctly --
corrections requested!) the view that the extensibility provisions of
CSS and HTML have had unfortunate consequences.  (I think the word he
used was "disastrous" but I could be wrong.)

I think what he meant was that if browser A supports a non-standard
element -- I'll use the 'blink' tag as my example -- and browser B does
not, then a user who wishes to make things blink must use browser A and
is thus locked in to browser A, and there is no interoperability.

I understand the situation rather differently (and did so through all
the years of browsers competing in non-standard extensions): the
extension rules of HTML have, as I understand them, several
consequences:

  - If you use a non-standard element like 'blink', it will have the
    defined effect only in browsers that support it.  In other browsers,
    the tags will be ignored and the contents displayed as if the tags
    had been absent.

  - In consequence, your document will be displayed without error
    messages in any conforming browser.  It may blink in some and not
    others, but the text will be there.

    That is one level or kind of interoperability.

  - If you want the document to look and behave the same way in all
    browsers, use only standard tags and use them only as described.

    That is a different level or kind of interoperability.
    
    Validation against the DTD was a simple way to check this, so for
    many years my rule was: to make your documents work consistently
    across all browsers, make them valid.

Since there was always a simple way to ensure that my documents would
work as intended in all browsers, I never experienced the web as
particularly suffering from a lack of interoperability.  Or at least I
never suffered from the kinds of interoperability problems some people
reported.  I chose to validate in part because I valued interoperability
more highly than blinking.  Other people chose differently, and I
thought their choice odd, but it was after all their choice.  They
valued blinking text more highly than interoperability.  (Why would you
validate HTML? a colleague once asked me.  The only thing that matters
on the Web is whether the document looks OK in Netscape 2.0!)

I have similarly never suffered particularly from the fact that browsers
have offered support for display properties not yet standardized in CSS:
I mostly don't use those properties, and I need to worry about browser
dependencies only to the extent that I need to work around bugs in the
support for standard CSS in browsers used by clients, or by users
clients care about.  When I do need to use non-standard properties, the
consequence has been that my stylesheet may need to say the same thing
multiple times, so that different browsers which can do what I want will
all do what I want, and say something different once, so that browsers
that cannot do what I want will do something more or less acceptable as
a fallback.  In those cases, the ability to have some browsers do what I
want (and by the time I am ready to use some new feature, it's almost
always most browsers, or all browsers except lynx) generally outweighs
the inconvenience of having to look up multiple ways of specifying the
styling.

In the HTML case, knowing what is standard and what is not standard
requires a specialized tool like a validator.  In CSS, my recollection
is that it's possible to see by examining the syntax whether
non-standardized properties are being used; since I don't have a CSS
validator handy, that is convenient.  In the case of SGML and XML,
having non-standard material be encapsulated in processing instructions
has meant that there has never been much of a barrier except my own
denseness to getting processors to do what I need without making the
document unusable in other processors.

In any language with syntactically distinctive pragmas or annotations,
like for example XQuery, the annotation and pragma syntax serves -- like
the processing instruction delimiters of XML -- as a convenient reminder
that what they express is not guaranteed to work in other processors.
The same is true of functions in non-standard namespaces.  So if I write
an XQuery module for one processor and then try to use it in another, I
know that those places may require attention.  And if my module uses no
pragmas and no annotations and no non-standard functions, I have the
expectation (usually justified by experience) that the module should
work in the other processor.  The interoperability problems I do
encounter generally have to do with whether particular namespace
prefixes are predeclared by default, and differences in support for
particular function libraries.  In particular, the pragmas and
annotations of XQuery have never yet caused me any interoperability
problems.

Interoperability is, I think, desirable for multiple reasons, and must
be judged in the context of those reasons.

In networking protocols, interoperability is (as I understand it) the
ability of a client from one vendor to interoperate with a server from a
different vendor, and it's desirable because it means I don't have to
acquire a different ftp client for every ftp server I might wish to
visit, or a different http client for every http server I visit.

When no network protocol is involved, "intereoperability" is often cited
as a goal, but without any test as concrete as the interoperation of
independently implemented clients and servers.  I have often come to
believe that outside of network protocols, the term has no well defined
meaning.  (I once witnessed members of a WG declaring that since their
spec did not define rules for invoking a processor, the fact that three
different processors produced eight different results on the same input,
depending on how the processors were invoked, did not constitute an
interoperability issue.  I believe that for those WG members,
"interoperability" denoted "good - I approve of it" and nothing more
than that.)  In more serious usage, the closest thing to a common
meaning appears to be that different implementations produce the same or
comparable results on similar inputs.

It seems evident that if one processor implements a particular bit of
functionality which another processor does not implement, then they are
not going to produce the same results with respect to that
functionality.  A processor with a Web interface and one with no Web
interface are not going to produce the same results on a test of their
Web interface.  A processor that supports an optional feature and one
which does not support that feature won't produce the same results on
inputs that require that feature.  The same is true for non-standard
extensions.  Those are facts about the way the universe is structured,
and they are not under the control of those writing specs for things
like ixml.

Why do we care about independent implementations producing the same
results?  I know of two reasons: first, in a standards context, that
kind of interoperability supports an argument that the spec is cleanly
defined and explicit.  If one of the specs is from outside the WG it
also supports the argument that implementing the spec does not require
insider knowledge.  

The second reason is that when different implementations produce the
same results for the same inputs, users can move from one implementation
to another and are not locked in to one implementation.  Obviously there
are going to be obstacles if the user chooses to use non-standard
function, or if somehow the user is inveigled into using non-standard
function unawares.

So when I am the user, I appreciate it when specs and implementations
make it easy for me to know when I am using non-standard features.  When
they do, I get to choose, and I do choose, based on the relative value
for me of the functionality in question and of being able to take my
inputs to another tool.  In different projects I choose differently:
when I wrote SQL databases refusing to use any non-standard SQL
constructs, I found that moving to a different SQL dbms was
straightforward.  When I use the transform() function in XForms, I do so
in the full knowledge that it is no longer part of the spec, and means I
am committed to using a particular XForms implementation.  If the XForms
WG somehow managed to force all implementers to drop non-standard
extensions, would I be grateful?  I don't think I would, because I find
the transform() function more valuable than the ability to move the form
to a different XForms processor.

If we care about interoperability because it gives the user the power to
choose, then making it easy to identify non-standard usages is an
important feature.  I disagree with the claim that the right way to
implement non-standard features is by making silent changes to the ixml
syntax, or by making a non-ixml processor.

Steven was arguing, this morning, as if we faced the choice between
allowing the implementation of non-standard features or forbidding it,
in ixml processors.  I think that we do not face any such choice.

We do not, in writing the ixml spec, get to decide what features will be
built into ixml processors.  We do get to define ixml conformance, and
the trick is as always to find a set of rules which will make the
concept of conformance useful enough to users and to implementors that
they will care about it.  As an implementer, a definition of conformance
is less useful if it prevents me from providing functionality I think is
worth providing.  As a user, a definition of conformance is less useful
if it means that every implementor who extends the spec does so in a
different way with different syntax and with no way for me to know which
parts of a grammar are standard ixml and which use extensions to ixml.
A definition of conformance is also going to be less useful to me as a
user if it has managed to shoo some implementers away.

Steven has repeatedly suggested that the focus in the use cases on
extensions to ixml is evidence that those who support pragmas really
just want pragmas as a license to implement a lot of non-standard
features.  I think this mistakes the case.  I did indeed come to view
pragmas as desirable when thinking about the possible extension of ixml
to attribute grammars. But if as a programmer I want to write an
attribute grammar in something resembling ixml notation, I don't need
permission or a license to do so.  What I wanted was a way to make it
possible to mark the non-standard extension so that a standard ixml
processor would not trip over it.

The choice we face is between providing a way to mark syntactic or
semantic extensions that is light-weight enough that implementers and
users will support it, and providing no such marking for extensions.  In
the one case, the hope is to channel non-standard extensions into
patterns that don't interfere with other processors; in the other case,
my fear is that since the spec provides no extension mechanism, each
implementer will invent their own.

Will a world in which extensions to ixml are not marked really be better
than a world in which there is a standard marking for them?

Assuming that I am able and willing to continue working on Aparecium,
will a world in which I remove any claim that Aparecium is a conforming
ixml processor and say only that it will handle conforming ixml input
correctly, and in which I object to any inclusion of Aparecium in lists
of ixml processors because the spec tells me it's not an "ixml
processor", really be better than a world in which Aparecium can be
described as a conforming ixml processor?

The CG does not get to decide what features are implemented in Aparecium
or any other processor. It only gets to decide how to define
conformance.  The CG should think hard about how conformance should be
defined.

My apologies for the length of this mail.

Michael


-- 
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
http://blackmesatech.com

Received on Tuesday, 29 March 2022 23:35:03 UTC