Subject: Re: Defining widget flow objects (was Re: Interactive XML) From: dvunkannon@xxxxxxxx Date: Wed, 1 Jul 1998 17:32:51 -0400 |
"Bill Lindsey" <blindsey@xxxxxxxxxxx> writes: David vun Kannon (dvunkannon@xxxxxxxx) wrote: >Then the W3C will be out of the flow object > business except for the case of HTML, which is a standard it owns. Then Adobe > can sell a package of PGML flow objects and a style sheet can turn database > output into hyperlinked infographics, ... Interesting idea, but don't think I agree. You seem to be saying that specifying the semantics of flow objects should not be part of the XSL mandate. Or, should it just be limited to two dimensional formatting flow objects? Yes, I am saying that the W3C , via the XSL mandate, should not arrogate to itself the task of defining all new flow objects. Doing so puts a bottleneck into the technology that will impede its adoption and usefulness. I would think that the specification of the behavior of flow objects is precisely the value of XSL. That's how we get inter-operability. If I have to write separate stylesheets for Netscape flow objects, and Microsoft flow objects, what's the point of using XSL? I might just as well use their proprietary, optimized XML styling languages. Your example addresses the same point as the exception I make above. The W3C owns HTML and has an interest in defining what "HTML flow objects" means. It is still quite possible that the Microsoft _implementation_ of the W3C HTML flow objects will include the <marquee> flow object and that Netscape will slip the <blink> flow object into their _implementation_. It might behoove the W3C to explicity disallow such actions, but that is beside the point. The point is that the W3C does not know every possible way XML documents can or will be "rendered." As in the milling machine example I gave earlier, a CML document of a protein could be rendered as the protein itself in a test-tube. A motion plan for a tele-operated robot might be styled into specific motor commands. These XML documents might be available on web servers, move over the Internet via HTTP transactions, but the W3C has no claim on the tag vocabulary or the flow objects that express the abstract functionality of the renderers in these cases. In the era when cameras, coffeepots and ATMs are connected to the Web, it would be putting your head in the sand to say that issues such as these are not apropos. On the flip side of the arguement, audio rendering via CSS is getting some attention, but when will we see audio flow objects in XSL? Who among those working on XSL is a domain expert in this area? Drive or get out of the way. Vector graphics - how can the W3C solicit submissions for a vector markup language that will be embedded in HTML and not be worried about the contemporaneous creation of flow objects? It is germane to ask for interoperable flow objects if the rendering environment is itself subject to an interoperability constraint. If all NC milling machines can be programmed in G-code, the set of milling flow objects should map nicely to that standard, but that is something for the milling machine software industry to accomplish, not the W3C. If the tele-operated robot is a one off experimental device that is being shared over the web to spread the cost around, then perhaps the consortium of users comes up with the motion plan vocabulary, but the robot designers write the flow objects, or perhaps a consortium of robot builders designs the set of flow objects and these guys just do an implementation of those objects specific to their robot. These examples suggest that since the W3C is never ever going to emit a blessed set of flow objects for milling machines or molecular assemblers or mobile robots, it should empower their creation by others in a standard way. Explain the design guidelines for flow object sets in general, tells us how to register them if we so desire, standardise DOM and namespace interactions - these are valid concerns of the XSL group. Mirabile dictu! I reread the 27 Aug 97 Note on the W3C site and behold: 6.3. Extensibility XSL will provide a mechanism to allow the specification of new flow object classes and characteristics for the new classes, by defining: interfaces for flow object classes and characteristics, and a mechanism in an XSL stylesheet for binding a name of flow object class or characteristic to code that implements these interfaces. So it turns out that I'm preaching to the choir - my sincere apologies! Just give it to us sooner rather than later - didn't this mechanism have to exist to plug in the existing two sets of flow objects, or are they hardwired special cases? Say it ain't so. Humbly getting off his soapbox, David vun Kannon XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Defining widget flow objects (w, Bill Lindsey | Thread | RE: Defining widget flow objects (w, JLemire |
RE: Interactive XML, Dan Hable | Date | RE: Defining widget flow objects (w, JLemire |
Month |