Summary of MWABP Discussion in 27th Nov

This is a summary of points discussed in today's call on the subject of
MWABP... I have extracted 4 concrete actions and 5 open questions. Two asks:

1. Please raise any other concerns & issues based on this draft as soon as
possible so we can aim to produce a draft suitable for public comments in
time for the moratorium on 18th Dec.

2. Please send me any editorial / typos etc and I will have a clean up of
the doc.


Thanks,
*
*Adam.*

Proposal: A new section 1.4.4 Device Capabilities
*
We should take the enumeration of how to extract device capabilities in
3.6.1.2 and move it into a general introductory section in 1.4.4 in order to
set-up expectation that many BPs require specific knowledge of the
capabilities of the device and how that can be done.


*Open question:* Should we update the structure of the BPs. Currently "What
it Means" / "How to do it". Should we add "Required Capabilities" to set
context for each BP. For example: *3.1.1 Retain Information for
Personalization *you need knowledge of what storage mediums are available on
a given device in order to make a decision here. *3.4.8 Sprite Static Images
*you need to know that a given device supports CSS clipping and positioning
and might not be appropriate to constrained environments.

*My concern:* Whilst valuable for a number of BPs, a large number will just
have "none" in this section... This is probably okay though.

*Open question:** **3.1.1 Retain Information for Personalization *is a bit
of a shopping list of mediums without any recommendations. We could (a)
Introduce more information to enable a  developer to navigate the decision
matrix of what to use when -- but this is potentially difficult to
express... (b) Remove these details and revert to the original intent of the
recommendation that you should retain state in the client so the user
doesn't have to enter it more than once -- but this is a little obvious and
doesn't contain much value on its own.

*Open question:* *3.2.2 Ensure that JSON datafeeds not Executable*. This is
a general Web BP but is it mobile specific enough? Perhaps the access of a
device to personal information makes this more relevant... (I don't think
this really scans on second thoughts since the feed is coming from the
server, not the device). It *is* important and non-obvious though so perhaps
that is sufficient motivation ?

*Open question:* *3.4.16 Use JSON in favour of XML* This is quite
contentious since XML is the standard... Option (a) Remove this and remain
silent on the subject. (b) Soften the wording...

*Personal eng experience:* In many years of Web-app development I have never
parsed XML on the client and don't see why you would? We could make a BP to
prefer XML on the grounds of security (eval is insecure) but it would be
making a BP that goes against what I know most people do in practice ? This
is also well evidenced by a survey of public data APIs which I think without
exception all provide a JSON projection.

*Open question:* *3.6.1 Prefer Serverside Capability Detection* is going to
be controversial... At least we need *ednote, *but first we should decide if
we really are comfortable with this as a recommendation. Proposed EDNOTE
text is :  "Please don't throw bricks at us, this BP is in response to
practical consideration of device limitations and fragmentation. Don't throw
bricks at us, we know this is changing so we aren't sure if it still
representative of what people are doing in practice or not, so please send
us your considered engineering experiences of whether this makes sense and
don't throw bricks at us."


*Editorial:*

Split up 3.2.2.2 and make more readable... Example -- will probably put this
in the Appendix as discussed at the F2F.

*3.5.6 Make Telephone Numbers Clickable* -- We should recommend *tel
*not *wtai:
*and remove discussion of UAProf since it is covered elsewhere.

*
Other TODOs:*

Add a section on SVG.