Brendan Eich <[EMAIL PROTECTED]> wrote > Bryan W. Taylor wrote: > 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.
OK. It did get a little non-un-anti-clear. I think I can restate what has been said somewhat understandably. Mr. Hickson made the original claim, which mentioned XPath, presumably as an example of what he considers a needless dependency in XForms. Ian Hickson <[EMAIL PROTECTED]> wrote in message > There is a third option, which is to work on alternatives to XAML that are > much more author friendly (for example, that don't depend on XPath, are > compatible with deployed content) and therefore more likely to succeed. I responded essentially saying fracturing standards isn't helpful: [EMAIL PROTECTED] (Bryan W. Taylor) wrote in message > Trying to forge you own standard and rejecting ones like XPath seems > neither "author friendly" nor "likely to succeed" to me. Doesn't the > IE monopoly make incremental extensions to HTML vitually impossible? To this you responded: > XPath is not used by web content authors enough to speak of, let alone > assert that it's friendly to them to support it. I took your argument to presume an implication that if a technology isn't used directly by web authors at a notciable level, then there is no benefit to those authors by implementing it. You assert XPath is such a technology and thereby rebut my point by using this implication to say I can't assert a benefit to implementing XPath when few authors know it. At this point, I challenged the logic behind the implication used to rebut me. In fact, I do assert a benefit to implementing XPath even if few web authors know it. The benefit is that of encapsilated reuse of capabilites such as XForms (or XSLT) that leverage it. Here you made the most recent point that I haven't proven my case yet: > Just because XPath can be encapsulated does not make it > author-friendly. Alternatives to XPath can be just as > well encapsulated and reused. These are two separate points, really. Your first statement is undeniably true. But note that XPath's encapsulability is not its only positive attribute. Developers have built things on top of XPath that have independent use to web authors. I gave an example of XForms implementing data entry for UBL schemas. XSLT has come in handy somewhere. Your other point is also true, but only for the future. Alternatives to XPath are not currently encapsulated and reused. You could choose to develop them and encapsulate them. This is what my original claim says would be "unfriendly". I'll enumarate some "unfriendly" results of competing standards. Suppose you invented MozPath. Call the problem space *-path. Since XPath has value outside the arena of web authors, it is not going away. Accordingly... 1) Interoperability would suffer as reusable tools based on XPath vs MozPath wouldn't work together. 2) Authors writing tools in the *-path space have to pick between the XPath market and the MozPath market both. Each market supports fewer total tool makers than a compbine *-path market would support. 3) Needed infrastructure tools would be duplicated using both technologies (eg, somebody will write XPathTest and somebody else will write MozPathTest) 4) The total learning curve to master all *-path techniques is increased, or people pick only one and thereby can apply what they know to a smaller domain. 5) The total *-path knowledge base is fragmented and knowledge sharing is impeded. > 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. In fact, I think XForms growth is most closely tied to that of XML Schema and to efforts to produce standardized schemas for specific topics. As things like UBL get created, it will be very natural to bring corresponding XForms with them. These become very highly reused and displace user development of cutstom solutions. _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
