Re: Need to re-work Chapter 2 substantively?

At 04:39 AM 12/12/2001 -0500, AndrewWatt2001@aol.com wrote:
>I guess since the XForms WD is almost at Last Call WD it is probably time 
>to raise an issue which has been niggling me for several versions of the spec.
>
>I think the division of Purpose / Presentation / Data is a little wooly.
>
>There are two issues, from my perspective:
>1. The examples in Chapter 2 are not ideally structured and need to be 
>re-drafted
>2. I suspect the Purpose / Presentation / Data structure itself may be 
>fundamentally flawed or redundant
>
>I feel a little like the wee boy daring to suggest the Emperor has no 
>clothes, so I hope you will be patient as I try to explain my concerns.
>
>Let me deal with the more superificial concern first. In the table in 
>Chapter 2 of the WD under the "Purpose" header we see terms like "Time 
>Card" and "Order Form". It seems to me that those **in terms of purpose** 
>(assuming it has its natural meaning) would be more appropriately 
>expressed as "Collection of worker time data" and "Collection of order 
>data". That sort of term/phrase is a "purpose", as I understand the term. 
>Terms like "time card" and "order form" are actually presentations (or 
>include an element of presentation) in my view.
>
>When you come to use phrases like those I have suggested under the Purpose 
>heading you tend to find that it is a litany of "[whatever type of] data 
>collection". And the data is listed under the Data heading.
>
>Which brings me to my deeper concern. Is the three way division of Purpose 
>/ Presentation / Data needed at all?
>
>For the scenarios which readily come to mind I find the three way division 
>working out as:
>1. Purpose - collecting X data
>2. Presentation - [potentially multiple]
>- order form on desktop PC
>- order form on palm computer etc etc
>3. Data - X data (maps usually - always??? - one to one with item 1, 
>Purpose).
>
>The obvious scenarios, at least to me, work out as
>1 purpose : multiple presentations : 1 set of data
>So if purpose and data map one to one do we really need a three way 
>structure?
>
>The other possible scenario is:
>1 purpose: multiple presentations : multiple sets of data (attenuated for 
>wee devices)
>But is that "one" XForms model at all? Or, when we have multiple sets of 
>data don't we, when we think about the situation more precisely, have 
>multiple purposes?
>
>As an example we might have:
>full personal info collection : desktop PC presentation : full personal info
>abbrev personal info collection : mobile phone form : abbrev personal info
>
>Again, in this type of scenario where the purpose (carefully spelled out) 
>differs the data set seems to move in parallel - again with a one to one 
>relationship.
>
>I hope I have been able to express why I have doubts about the current 
>presentation of Chapter 2 and the underlying structure fairly clearly. If 
>WG members have scenarios where we have
>1 or many purposes : multiple presentations : 1 set of data
>then I guess we may actually need the three way Purpose / Presentation / 
>Data division.
>
>If not, is simplicity and clarity not better served by a two way 
>Presentation / Data Model view?
>
>I would like to suggest that the WG considers that a two dimensional 
>Presentation / Data Model explanation/structure is more concise and 
>perhaps better represents the potential advantages which XForms brings to 
>the Web.
>
>Andrew Watt

I agree that, at the very least, as it is spelled out now there's not a 
clear need for the 3-way distinction.

I would even argue that at least in the example you cited (full personal 
info, abbrev personal info), they share a common base purpose - info 
display/collection - as likely all forms will share, and that the 
distinction between them is relevant primarily in the clients targeted for 
rendering.  I guess you could argue that listing a purpose "abbreviated 
data collection" is a better, more generic description than saying "this is 
for a small device."  But then it would be nice to see an example of the 
"purpose axis" with some meaning outside of the "client constraint" category.

At the very least I think there is room for clearing up the readability of 
this section.

Jim



--
jim@jbrix.org

Visit www.jbrix.org for:
   + SpeedJAVA jEdit Code Completion Plugin
   + Xybrix XML Application Framework
   + other great Open Source Software

Received on Wednesday, 12 December 2001 11:14:54 UTC