Re: Defining widget flow objects (was Re: Interactive XML)

"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