John Boyer wrote:
1) Why do you say "XForms is also requried to be used within an XML
document served with an XML MIME type..."?
XForms defines the host document to be XML and XML documents should be
served with XML MIME types (or at least a MIME type that is defined to
use XML processing in some way) in order to be processed as XML. See my
previous e-mails that touch on this issue.
One of my products serves XForms in a document with the MIME type
application/vnd.xfdl. And the product works in IE and Firefox, and
there is an alpha version under Safari.
That's fine. It's a vendor specific MIME type and you can define it to
be for whatever you like, including XML content. Presumably, your
application knows that it needs to handle the XForms content in a file
delivered with that MIME type as XML and there is no problem with that.
Another of my products implements XForms without even serving it to
the client by translating to XHTML, which works (!) on windows, mac
and linux web browsers that don't even have the "benefit" of WF2.
Are you saying that the browser doesn't receive XForms markup at all in
this case? Is the system converting the XForms markup on the server to
XHTML <input>, <select> and <button> elements prior to sending it to the
client?
If so, that's fine. How the content is produced on the back end is
irrelevant to this this discussion. In fact, if I've understood this
correctly, your system could even benefit from the proposed controls in WF2.
So, the first point is that the web is larger than what web browser
makers choose to implement. Knowing that, they gave us tools like
plugins.
That's true, but any language intended as a replacement for HTML either
needs to become as widely deployed amongst users, as quickly as
possible, and to provide adequate fallback mechanisms which will be
heavily relied upon during the transitional period.
2) Why do you say "text/html is not XML"?
Um. Because it's not! See earlier in the thread where it was mentioned
that XHTML documents served as text/html are not treated as XML, but
rather as any other erroneous HTML document, in tag-soup parsers.
Also, keep in mind that the "XML Data Islands" feature implemented in IE
is a proprietary, non-standard and non-interoperable extension. It
cannot be used as an argument against this because it doesn't really use
XML processing. It seems to simulate namespaces by generating a
proprietary <?xml> SGML-like PI and treats ill-formed markup in the same
insane way it handles HTML, by building a broken DOM. In other words,
it shouldn't even be called "XML" because, although it shares some
similarities in syntax, it's not treated as such.
The server-based product I describe above has been shipping for years
now, and it heavily relies on the fact that browsers do know exactly
what to do when the HTML content is XHTML compliant.
Are you saying that browsers handle XHTML as text/html any differently
from HTML? If so, that is simply not true. If not, please clarify.
Starting in 1998, the W3C decided to migrate the web toward XML
(http://www.w3.org/MarkUp/future/), and this stuff *does* work in the
browsers!?!
It may appear to work on the surface, but you really need to consider
the many significant differences between HTML and XHTML processing,
particularly in relation to style sheets, the DOM, scripting techniques,
parsing and whole lot more.
3) When you say "The vast majority of authors don't use XHTML, they
use HTML",
I believe you are actually supporting the point I'm trying to make.
Although we want to lead the way to XML, it is a challenging and
long-term process. People won't update their content without a
reason. The more reasons we give, the more likely the upgrade. The
more who upgrade, the more reasons we can give because ever more
interesting tools and applications can then be applied to that
content to aggregate, to syndicate and to consume it in ways we can't
even begin to imagine right now.
But we shouldn't force people to use a new technology by saying if you
don't, you'll be left behind. The transition path needs to be as smooth
as possible.
4) When you say "The approach taken by the WF2 script, however, does
not require the user to have installed some plugin locally, it will
function as long as they have JS enabled."
I believe you are continuing to mislead, as XForms can also be
implemented in JS only (there is such an implementation).
But for such an implementation to function in IE, it needs to be served
as text/html, which, as I have already stated, is not appropriate!
Using such a script in browsers that actually support XHTML, however, is
fine.
Please allow XForms all the same tools that you allow WF2, at which
point you will find there is no need for this divergence.
The divergence happened 8 years ago when the W3C decided to move from
HTML to XHTML.
5) When you say "XForms also fails to provide for graceful
degradation in current UAs, like WF2 does"
I believe you have missed a whole segment of this ongoing thread,
esp. the main #1 highlighted axis mentioned in the IBM position
statement. We like the ease-of-authoring features, and we sure wish
the proponents of WF2 would have just joined the XForms WG and
contributed because if you had, then not only would XForms 1.1 be a
recommendation already, but it would even have the features that you
want in it.
But one of the major features we want is true compatibility with HTML
without using some pseudo-XML nonsense, but which you seem to be against
by saying the X(HT)ML is only way forward; yet still (strangly)
advocating the ability to have XHTML+XForms "work" when treated as HTML?!
It is just too easy to say <input name="X" type="integer"/> is an
ease-of-use syntax that implies the creation of an XForms input
control bound to a node with local name X and a binding between X and
the type xsd:integer.
Possibly. Are you suggesting that the XForms content could be bound to
the input element in XBL sense (i.e. using shadow content trees, etc.)
or that the input element in the DOM gets replaced with the equivalent
XForms content? If it's something completely different, please explain.
So, since we agree with you on this point, maybe you would be
interested in joining XForms and contributing this feature to the
language.
I'm more than happy to contribute whenever I can.
This way, you get the syntax we all want, and it gets unified under a
conceptual model that the author can then graceful scale upward as
his data modelling needs increase.
If the spec can be developed in such a way as to provide a transitional
path like that, that would be great!
Keeping in mind that I am stressing adamantly that the most prevalent
of UAs to which you referred can absolutely, positively and without a
doubt handle it when you send it text/html content that happens to be
well-formed XML.
Keeping in mind that the most prevalent of UAs to which I referred will
absolutely, positively and without a doubt attempt to handle *whatever
garbage you throw at it!* That doesn't make it right to do so.
--
Lachlan Hunt
http://lachy.id.au/
