[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Topics of keen interest to me ... how about you?

• From: cbullard@hiwaay.net
• To: David Lee <dlee@calldei.com>
• Date: Wed, 14 Aug 2013 09:38:18 -0500

Close but how do you "know" and how dynamic is what you "know"?

An example:  given a DTD/Schema that accounts for as many potential  
states of an instance as the designer can conceive, write a FOSI that  
renders all of them. Say combinatoric explosion.   By metaphor, the  
Schema is as wide as the Mississippi River at flood stage but the  
actual water is a creek in the dry season.

To efficiently data drive the systems, your global domain is locally  
circumscribed to real world measurements.

Real world:  the author gets an editor that enables a very large  
number of possible expressions.  The FOSI, XSLT-FO, CSS, etc. has to  
render to PDF.  You want to work out in advance how many of the  
possible conditions are probable and do those first.  It is like FMECA  
analysis: a bottom up analysis of possible failures based on part  
failures.   Two problems of bottom up analysis:

1.  Some failures are unlikely but possible.  You can find yourself  
writing a very dense failure table that is only sparsely addressed.

2.  Bottom up failures are not necessarily combined, that is, you  
don't necessarily have an event-oriented failure tree that can handle  
multiple failures in a given environment.

The same problem shows up in the FOSI design.  It is a bottom up  
description to which you add contexts for local conditions.  In a  
DTD/Schema design with a lot of shared constructs, the nesting or  
recursion is vast and you only have global variables to describe that  
and/or microparsed system and user defined elements to generate data  
given novel conditions.

In practice, you cut the schema or DTD down once with practice you  
know which conditions are useful and code other artifacts such as the  
FOSI to that subset.  Drive the production work against that subset  
and add to it as needed.  At delivery time validate against the record  
of authority (the Big Honking Schema Cited in the CDRL) to prove  
compliance.  Be sure the Little Honking Schema is a proper subset.

There is no means to escape measurements in real world dynamic  
systems.  Data driving hits the wall if you can't incorporate  
measurements and that is where data-driven systems can fall apart.

len


Quoting David Lee <dlee@calldei.com>:

> I have a hard time comprehending ... could you confirm I got the point please
> You are saying (greatly simplified)
>
> If you know what your data looks like at app build time then a  
> hard-coded GUI is better.
> If you dont know what your data looks like at app build time then a  
> data-driven GUI is better.
>
> Is that the idea ?
>
>
>
> ----------------------------------------
> David A. Lee
> dlee@calldei.com<mailto:dlee@calldei.com>
> http://www.xmlsh.org
>
> From: Len Bullard [mailto:cbullard@hiwaay.net]
> Sent: Tuesday, August 13, 2013 7:20 PM
> To: David Lee; 'Peter Hunsberger'
> Cc: 'Costello, Roger L.'; 'xml-dev OASIS'
> Subject: RE:  Topics of keen interest to me ... how about you?
>
> Data-driven models work nicely for plotted events.  IOW, if you are  
> feeding data to a model across a process, as long as you understand  
> the event space, you can control that model.   The problem of  
> GUI-as-BoxesOnAScreen is most of the states are static or enumerated  
> and data driving it where the drivers are HUI inputs to machine  
> interfaces even if gesturally rich is objective impoverished.  The  
> model of finding resources and acting on them is basic, thus REST.   
> Almost all of the richness comes from domain specific-events and  
> conditions.
>
> Data driving comes into its own when you drive the model against a  
> dynamic event framework that is outward facing, e.g., a mission  
> environment with waypoints.  Then everything is a sensor and  
> everything else is a data resource be it internal or environmental.
>
> len
>
> -----Original Message-----
> From: David Lee [mailto:dlee@calldei.com]
> Sent: Monday, August 12, 2013 10:25 AM
> To: Peter Hunsberger; Bill Kearney
> Cc: Costello, Roger L.; xml-dev OASIS
> Subject: RE:  Topics of keen interest to me ... how about you?
>
>> peter says
>
> I find it interesting that "data driven" can someone how be viewed  
> as in opposition from giving the user a better UI.  In the end, the  
> metadata that should be used to build user interfaces is still data  
> and exposing that as early and directly as possible and giving the  
> users ways to manipulate that data is the best way to build a  
> powerful user interface.  Exposing it directly as XML is probably  
> not part of that scenario, but XSLT on top of XML can be directly  
> below the layer that is exposed to the user and is very flexible and  
> powerful.
>>
>
>
> I come from a long history of being pulled into doing UI when I  
> wasnt really good at it
> (20+ years ... think X10, DOS ... and on through all incarnations of  
> Windows, Mac, Devices , Palm, PPC, BlackBerry, iOS .... )
>
> "Data Driven" GUI has always been a holy grail.  In some closed  
> systems it succeed quite well ... especially when the expectations
> of the users were modest and the computer capabilities were equally modest.
> But as time advances I find the concept on less solid grounds then  
> my liking.  I spent a day at Balisage Pre-conference hoping that
> what I didn't know about XForms would enlighten and endear me to the  
> concept.   I am afraid it did not.
> I simply have not seen how a data driven UI ( unless that data is  
> presentation oriented +  program code) can achieve what "ordinary  
> users"
> expect out of a "normal UI".    There are certainly a lot of cases  
> where the UI can meet the minimum standards, and balanced against  
> the problem of multi devices and variety of input is a good  
> tradeoff.  But when you hit the bounds of "application" where users  
> expect that it was
> actually written for them ... and where the function and display  
> (the whole UX)  is more than filling out form fields or showing some  
> tables,
> to me, I have not seen a "Data Driven UI" that meets that  
> expectation - unless you constrain the space very tightly.  That is  
> you create a very good UI framework then plug in the data driven  
> stuff to fit it.  But I have used many such things and while they  
> work well within their box, if you push up against the edges they  
> fail miserably.
>
> I would love to have someone show me the Holy Grail ... I still  
> think it might be out there, but have not found it myself.
>
> ----------------------------------------
> David A. Lee
> dlee@calldei.com<mailto:dlee@calldei.com>
> http://www.xmlsh.org
>
>
>
>
>

• References:
  • RE: Topics of keen interest to me ... how about you?
    • From: David Lee <dlee@calldei.com>
  • RE: Topics of keen interest to me ... how about you?
    • From: "Len Bullard" <cbullard@hiwaay.net>
  • RE: Topics of keen interest to me ... how about you?
    • From: David Lee <dlee@calldei.com>