[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: [xml-dev] 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: [xml-dev] 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: [xml-dev] 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
>
>
>
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]