RE: Summary of MWABP Discussion in 27th Nov

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."

so what do you propose for capability detection?

And what do you mean by capability detection? That's the key thing to my mind.

One case of capability dectection can be, for example, what JS DOM methods are supported by the device, which can be easly checked using

if(document.getElementById) {
xxx
}
else {
             yyy
}

However, other capability detection such as supportedImageFormats or supportedNetworkBearers, vendor, model, inputModes … i.e. typical a priori known information about the device will need a DDR and a server-side capability detection module.

about the editorial note, a bit worried about "please send us engineering experiences", if I'm as a reader of the document see such editorial note I would think "this guys are defining best practices without having engineering experiences … nonsense"
I think in the group there are companies with engineering experiences that come from years and server side capabilities dectection has been there for years and the recommendations of not relying on user-agent spoofing at the Javascript level, and use Javascript testing functions are well known … so …

De: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] En nombre de Adam Connors
Enviado el: jueves, 27 de noviembre de 2008 17:20
Para: MWI BPWG Public
Asunto: 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<http://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.




Editorial:

Split up 3.2.2.2<http://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.