Brendan Eich <[EMAIL PROTECTED]> wrote
XPath is not used by web content authors enough to speak of, let alone assert that it's friendly to them to support it.
The observation doesn't support the conclusion,
What conclusion? My observation that XPath is not used by authors much seems to be true, and you don't dispute it.
My conclusion was *not* that XPath is therefore not "author friendly"; I wrote no such thing (although as a matter of fact I do question XPath's friendliness over alternatives that are already known by developers). I wrote that it's simply not used enough for you to assert that it *is* "author friendly".
Your words, not cited above, asserted that rejecting XPath seems not to be "author friendly". Here's the citation:
> Trying to forge you own standard and rejecting ones like XPath seems > neither "author friendly" ....
That's an extraordinary claim, given that web content authors can't use XPath in web content today, because it's not supported in most browsers. Where is your evidence for this claim?
Independent of XForms, XPath, etc., we seem to be having significant problems communicating, either due to rhetorical or logical bugs in ourselves. Let's debug those first, if possible.
and overlooks one of the biggest value of following standards. If you will study the example below, I think you may start to see why XForms is going to be extremely valuable.
Your example below is familiar to me and to anyone who has read the XForms spec. But it fails to justify your assertion that "trying to forge your own standard and rejecting ones like XPath seems [not to be] 'author friendly'." Just because XPath can be encapsulated does not make it author-friendly. Alternatives to XPath can be just as well encapsulated and reused.
Some developer could easily write corresponding XForms pages for the different use cases associated with modifying these schemas. Eventually, any web author could reuse them, without really needing understand XPath, XML Schema, or XForms.
I understand how XForms' separation of duties, etc., can be helpful, so you needn't belabor that (but thanks for the UBL links). I have no doubt about its utility for certain use-cases, but on the other hand, XForms is not burning up the market, and not for lack of browser support -- there are plugins and server-side processors that translate to browser formats.
Since XForms simply is not going to be supported natively in any of the top four browsers soon, and only later, at some cost including a high opportunity cost, in Mozilla, I'm not sure how evangelizing it to me or others here helps. What I say, whether I cheer-lead, has nothing to do with the lack of native browser support in IE, Opera, or Safari. This is all off-topic in m.layout, of course, but let's finish this thread here if we can.
Let's suppose that XForms were reusably well-used, so that duties were separated, etc., such that it didn't matter to most web content authors working on the forms presentation whether XPath were used, or JavaScript instead, or something completely different. Then there would be no author-friendliness issue for or against XPath.
But the fundamental problem remains: if you want browsers to support XForms, then browser implementors have to support XPath. And XML Schemas. And other things that cost a lot in code footprint, time to market, opportunity costs from hacking on them instead of doing many other necessary or optional-but-profitable things, etc.
If XForms were so obviously a win for Mozilla, and *only* for Mozilla among the top four browsers, to implement and ship by default, I think we would know it by now.
You still have not told bz what bugs he shouldn't have fixed in the last two years, BTW.
/be _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
