[whatwg] A Quick Greeting and Some Comments

[Didier PH Martin]

Hi Kurt,


> 	e) Given all that, walking away completely from XForms is probably
> not
> the most effective way of working, especially as it does have a couple
> years headstart over WHAT.

I agree. What should be done instead is finding a way to expand it with new
control or define how new controls can be declared and used in an Xform.
These controls could be created from code+ elements (behavior?, xbl?,
whatever).

> 
> 3) I wrote an XQuery book three years ago, as part of a Wrox team. I wrote
> an XQuery book last year as part of a SAMS team. Between the two, I've
> sold 30 copies. I'm convinced that XQuery, which represents the collective
> work of the largest database manufacturers (and is one of the few W3C
> specs actively supported by Microsoft) will be stillborn. Why? Because it
> confuses a very real need (the need to extract XML content from a data
> store in a consistent manner) with a perceived marketing need (the need to
> create a "better" SQL). I raise this point as a cautionary one; does WHAT
> provide enough of a benefit that browser vendors, web developers and the
> public will all see it as satisfying a real need?

Who knows....

> 
> 4) Another cautionary tale. The wireless phone industry all lauded WAP/WML
> when it first came out, saying that it would revolutionize the way that
> content was handled on the handheld web. Yet today, WAP/WML is largely an
> irrelevancy in the face of chips that have become powerful enough to
> handle more traditional HTML views. Transitional technologies require the
> same amount of time and energy to implement as new technologies do, the
> same amount of programming to implement into the firmware of cards, the
> same adoption curve that "bleeding edge" tech has.  As I see it WHAT is
> fairly conservative in that it recommends incremental changes into the
> browser environments rather than wholesale ripping out of core pieces of
> functionality. Yet if the same problems persist with the newer model as
> does with the older one, have you necessary made the problem any easier,
> or have you simply created more incompatibilities between systems?

You know Kurt being able to add behavioral extension to the existing visual
object structure (in the case of XHTML or SVG) can be quite powerful. Just
take a look at this work in progress, still very incomplete but works in
both Mozilla and IE. I used an XML based language to define the object model
(PDML my own invention used to encode/serialize prototype/instance and class
based languages), XSLT, HTML and ECMAScript. Having something like behavior
make it easier to re-use code and manufacture ready to use components. See
the link below for the work in progress webtop.
http://netfolder.com/pdml/webtop (you'll have to set your popup prevention
tool to OFF since it opens a fullscreen window to display the webtop). In a
nutshell, we can quite a lot with existing visual object but still need some
tools to make it easier, facilitate code re-use, facilitate content edition.
With just that, your limit is your imagination.....

> 
> 5) I have written behaviors for Microsoft itself; it was cool technology
> back in 1999. Today, I typically implement those behaviors using external
> namespaces and the intelligent use of XSLT. This takes a little more work,
> but the code is generally much cleaner in its implementation. This is a
> case of different strokes for different folks, though I think there are
> some things that can and should be taken from this.

I tried this too Kurt but I also discovered that life could be a lot easier
with behavior even with XSLT transformations. My stylesheets are also a lot
simpler when behaviors are used.

> 
> Realistically, behaviors do not exist in isolation. Instead, you typically
> have clusters of tags and attributes on those tags that determine the
> basal characteristics of the behavior, bindings that connect such elements
> with others, and sets of methods that can be called on these elements.

Having the capacity to attach behavior to more than one element and to
declare it outside of the document helps a lot. Take for instance this use
case:

You have to insert two sortable table in the same document for some users
and two sortable and editable tables for some other users. In that case,
attaching the same behavior to two <table> elements in the same document
helps and being able to declare the attachment outside the document helps a
lot too. I just change a single line: the CSS inclusion declaration, one
stylesheet for one user and another one for others. I can do that directly
in XHTML (rwo different documents), through code (an ECMA script changing
the CSS reference or the behavior property) or through an XML transformation
using XSLT (injecting different CSS declarations).

> 
> 6) Bundled behaviors of this form also bypass the CSS mechanism that I
> find so cumbersome when dealing with behaviors in IE. I've written several
> books on CSS; it is an antiquated technology that is difficult to extend
> into XML without a huge amount of work, and it is rapidly being deprecated
> in most new web browser technologies in favor of some form of NON-STANDARD
> styling mechanism. This to me seems to be the REAL hole within the W3C
> universe, and it shows up everywhere; there is no reason when dealing with
> XML that we should be accessing a non-XML text file that defines in a
> complex parsing manner a limited set of stylistic attributes that then
> rely upon a difficult to use cascading model. Binding behaviors into the
> model seems to me the height of poor planning.

Maybe but CSS properties are tremendously useful to build rich internet
applications. For instance, changing style when your mouse is over an
element. I also wrote books on XSS and XSLT and disagree with you on this.
However, I do not know if the CSS usage is decreasing among web developers,
but I noticed that web developers are outsourced :-)

> 
> 7) Don't discount SVG. I think that SVG is sitting just on or slightly
> past its inflection point; from my vantage point studying the technology,
> this year will see it become pervasive everywhere EXCEPT within Internet
> Explorer, either directly or through third party extensions. If you treat
> SVG as simply another behavior a la #5, or better, treat it as a behavior
> implementation with a generic behavior interface, then you can continue to
> use the simplified forms of WHAT while admitting the new technology. This
> should, in my mind, be an underlying principal for WHAT - that the
> standard should NOT out of hand eliminate other technologies simply for
> the sake of simplicity, especially when those technologies can buy you as
> much as SVG can.

I agree.
> 
> 9) Perhaps a continuation of #5. The goal with any such system is to push
> declarative rather than imperative solutions whenever possible, and to
> push generalized DOM solutions over application specific ones when you
> can't. My own estimation of DOM has changed considerably over the years.
> At first, I saw it as a transitional technology, but increasingly I'm
> coming to see DOM as being a a generalized interface language that
> eliminates much of the complexity of OOP framework systems. Again SVG is a
> good model for this - rather than creating a complex set of customized
> components (a rect object, an oval object, whatever), each with its own
> access methods and procedures, you create a generalized DOM for working
> with the object in an abstract fashion, setting the position by changing
> the value of an attribute, adding or removing objects into the model
> through straightforward DOM insertions/deletions, and so forth.

This model is made tremendously easier because of ECMAScript and its
prototype/instance based architecture. I would prefer that instead of trying
to kill all birds (mean here adapting to java) that the workgroup would have
made a better match with protype based languages like the standard
ECMAScript. For instance to set or get an element property as simply as:

objectID.propName = "10px" instead of:
var objectID = window.document.getElementById("objectID");
objectID.setAttribute("propName", "10px");

The former is:
- a lot more easier to write, remember, debug, understand.
- less verbose
- is a more OO lamguage expression.

The latter:
- look like an afterthought patch
- an unnecessary remote procedure call kind of setter.

I would attack this first, make it simpler to write code in the web
environment and sticking for the moment to ECMAScript and design the
interface well instead of being to be mediocre in all languages.

> 
> Where's the advantage here? Consider an e-mail system in which you could
> effectively represent everything as an XML object. You wanted to find all
> mail written by kurt at kurtcagle.net written after June 1, 2004? You can use
> XPath as the universal addressing system into the DOM, making a call such
> as
> 
> kurtLetters = incomingMail.selectNodes(".//mail[from='kurt at kurtcagle.net'
> and sent gte '2004-06-01']")
> 
> You need to know the schema, but you don't need to know a specific API --
> and what's more, you don't need the same API on different systems that
> still implement this schema.

I agree, tremendously useful.

> Okay, I've probably gone on longer than I should (and will probably be
> permanently banned from this mailing list as a consequence) but I just
> wanted to stress that a back to basics movement is fine so long as people
> understand that such basics should be used as a guideline, not a
> regressive step. Anyway, I'm looking forward to the discussions on this
> group.
> 

Surely not Kurt, good to see you join the discussion.

Cheers
Didier PH Martin