Re: XForms Use Case

Yes, it's a flame. My apologies for offending delicate sensibilities.

The goal here has been to find a way to identify those use cases where XML
and HTML are going to integrate - poorly or not. Michael Kay laid out a very
cogent case for XForms being one of those use cases, and it was immediately
pounced upon as being an inferior technology to the obvious superiority of
HTML5 or Web Forms 2.0, or fill in the blank HTML goodness. Frankly, I don't
care a wit for Web Forms 2.0, because MY use cases are for technologies for
which I don't want to spend a huge amount of JavaScript code in order to be
able to support those applications.

I think somewhere along the line in extolling the virtues of the HTML model,
Ted and you and others on the HTML5 WG have made a profound fundamental
assumption - that HTML5 is a pristine garden that can accommodate all
possible cases, that there is no real need for extensibility, and that there
is no room for any dissenting opinion in that regard - if it can't be
rendered with what's provided out of the box and a boatload of scripting,
then it shouldn't be in HTML5.

>From what I've been able to tell, the point that Michael made was that IN
THE REAL WORLD people WILL extend out of that garden if they can ... and it
was precisely this extent that caused so many problems with the HTML4 side
of things. HTML5 is making the same mistake that WAP/WML made about a decade
ago - if you create the RIGHT core set of properties for your ontology and
define those ontologies closely enough, then there's no real need for
extensibility. WAP/WML failed. It failed primarily because of this very
assumption. Vendors added features outside of this in order to differentiate
their product, programmers added new layers to get around problems that
weren't conceived of in the original design, and web designers largely
ignored it because those same programmers offered better looking, better
acting "extensions", but since there was no mechanism for such extensions,
they were ad hoc and random.

In my day job, I'm a data modeler. I deal with such ontologies all the time,
and what I have found time and time again is that you CANNOT describe a
problem domain completely. If you're stupid, you limit yourself to a fixed
set of terms, then force developers to work around that set, often assigning
meanings (and hence interpretation and behaviors) that run exactly counter
to the usage that you yourself had foreseen. If you're smart, you design
with extensibility in mind, you provide a mechanism for extending your
capabilities that still allows you the means to control the core technology.
That strategy has worked well with XQuery and XSLT. It's a strategy that
XForms-WG is examining, and I think that's one of the reasons that it has
had only limited success, but it is also a strategy that I ultimately expect
to be adopted.

However, the point that I'm trying to make here, and what I was objecting to
in Ted's commentary, is that until this fundamental point about
extensibility (and the inevitability of that) is recognized, acknowledged
and incorporated, HTML5 is a language strikes me as a "newbie" language -
focused primarily on providing ease of use over anything else. In point of
fact, the leading edge of development will be precisely those 20% or so who
do push the envelope, who do try to make it act in ways it wasn't intended
to. Make it easy for them to do that, acknowledge that there is a place at
the table for the power user and the guru who may in fact know more than you
do, and you have something that ultimately can carry us forward for another
decade anyway.

Well, what about XHTML5? This seems to be a common refrain on this site from
the HTML5, that if this was such an issue for the developer, then they
should use XHTML5. If the underlying parsing models were consistent, that
would make sense, but they're not. XHTML5 will render differently than
HTML5. XHTML5 extensions won't work in HTML5, and perhaps most damning,
there is NOTHING that says that a given user agent needs to support XHTML5.
We're right back to forking web page content, only now text/xml+xhtml
becomes the new unsupported Mozilla vs IE (or whatever the newest browser du
jour).

So what's the solution to this? I think it's THIS that we're trying to solve
here, when you get right down to it. We need to resolve the question of
foreign content and extensibility not by hacks like putting everything into
MathML (that's a frickin' kludge, is what it is) but by trying to find a
common extensibility solution that will work in both HTML5 and XHTML5 for
some arbitrarily large percentage of cases. We need to get away from
thinking about HTML5 as the Blessed Word and start thinking about it as an
ontology in a sea of other ontologies.

I realize that this is hard for the WHATWG group - and I'm not trying to be
sarcastic here. The mindset that has informed HTML5 has been a
fundamentalist one - this ontology is privileged over any others for use
within browsers. I think perhaps ten years ago that was true by dint of
historical precedence - the first browsers were intended to render HTML, and
it has to be seen (and even I would agree with this) as being a foundation
language, that minimal subset of ontologies that the browser will support
among all others. However, I'd contend that by locking out foreign content
and extensibility (and note that I'm not even talking about XML here), by
refusing to admit that there may be other ontologies that other people may
be interested in working with in this universal piece of software, that you
are trying to regain a historical position that is no longer as relevant,
and that will become increasingly irrelevant as alternative ontologies
representing different viewpoints become increasingly commonplace as
document stores. These stores are non-proprietary; this is not word vs PDF,
this is XML (or zipped collections of XML or even alternative data formats)
that could be potentially rendered  via some kind of transformative
technology.

Here is my challenge to you - move beyond the viewpoint of seeing HTML as
being privileged and see what the consequences of that - not the
implementation issues, but the usability consequences. Suppose that your
browser could support a zipped DITA file set to render help content, could
render 3D content inline with declarative content, could invoke a MIDI file.
Suppose that each browser could act as a generalized complex record viewer
for medical health records, or could natively display an Atom or RSS feed
without being constrained by a lot of JavaScript code. I am not asking what
tag could you add to HTML5 that would let me have this functionality, I'm
asking how could you provide a mechanism for extending the browser model so
that the web developer can create their own tag library to accomplish that
support.

That's the difference in world view that I think the HTML5 and XML groups
are facing. The shape of the end tag, whether attributes must have explicit
values or not, to me these are comparatively minor issues. The bigger issue
is whether it is the browser vendor or the web developer that ultimately is
responsible for what the capabilities of the browser - if AJAX Is any guide,
there are a heckuva lot more web developers than browser vendors, and they
WILL push to get out of any closed system in very short order.

Kurt Cagle
XML Architect
*Lockheed / US National Archives ERA Project*



On Wed, Jan 12, 2011 at 7:06 PM, John Cowan <cowan@mercury.ccil.org> wrote:

> Kurt Cagle scripsit:
>
> > May I make a recommendation.
>
> That's not a recommendation, it's a flame.
>
> > I do think,
> > however, that the general impression that many people have of this
> process
> > (speaking as someone who is setting standards within a large federal
> agency)
> > is that, as with many other aspects of HTML5, that this preoccupation
> with
> > reinventing the wheel to actively exclude XML is frankly getting old and
> is
> > throwing away a huge amount of accumulated knowledge about what works and
> > what doesn't, on the basis of what appears to be ego. Maybe I'm wrong -
>
> Wrong or not, the words "throwing away a huge amount of accumulated
> knowledge about what works and what doesn't" has been applied to both
> sides already.  I suggest not going there again.
>
> As Spider Robinson says, it's not who picks the most potatoes, it's can we
> get the potatoes picked before winter comes.
>
> --
> John Cowan  cowan@ccil.org  http://ccil.org/~cowan
> The penguin geeks is happy / As under the waves they lark
> The closed-source geeks ain't happy / They sad cause they in the dark
> But geeks in the dark is lucky / They in for a worser treat
> One day when the Borg go belly-up / Guess who wind up on the street.
>