New API Document Structure

[nrooney]

Last time we spoke we were thinking of making it similar to Dom’s "Standards for Web Applications on Mobile: current state and roadmap" document (http://www.w3.org/Mobile/mobile-web-app-state).

What I want to figure out now is how we should structure the API Document. Effectively we'll be listing Native APIs and the platforms that support them, then we'll be stating somewhere whether they have been implemented on the web yet or not. So, we could group APIs by categories, as in the "Standards for Web Applications on Mobile: current state and roadmap" document.

If you guys agree with this - can we copy the structure from the "Standards for Web Applications on Mobile: current state and roadmap" document for our document? Or do you think we need to add or remove some categories. The categories currently are:

• Core Web Design and Development
  • Graphics and Layout
  • Device Adaptation
  • Forms
• Data storage
• Media and Real-Time Communications
• Usability and Accessibility
• Device Interaction
• Network Integration
• Application Lifecyle
• Payment and Services
• Performance & Tuning
• Security & Privacy

[leandromsales]

Hi Natasha,
I agree this, at least just to start it is ok for me. Once we start the work we can reorganize, if necessary.

I have installed the pandoc and run the "make" command. We will keep you posted about our progress.

Thanks!

[d4n1]

I agree too, bu I think that we could add more 2 categories:

• Hardwares available
• Licenses

What do you thing about it?

Thanks.

[nrooney]

Sounds good to me! i will add!

[nrooney]

Ok, Given the great work @d4n1 has been doing, I have rejigged the categories for the document to be the following, can everyone let me know what they think? If you're happy with this, I can make the changes to the doc!

_Device Hardware Interaction_
battery.json
bluetooth-le.json
bluetooth.json
compass.json
accelerometer.json
magnetometer.json
nfc.json
wifi-wake.json
vibration.json
usb.json

_Device Apps Interaction_
calendar.json
contacts.json
push-notifications.json
globalization.json
ime.json (not sure about this here)
local-notification.json

_Geo_
geofencing.json
geolocation.json
indoor.json
globalization.json [2]

_Core Device, Task Management and Scheduling (Service?)_
background-scheduler.json
cpu-wake.json
device-info.json
screen-wake.json

_Media and Real-Time Communications_
camera-stream.json
media-play.json
media-capture.json

_Storage, File and Cache Management_
file-transfer-background.json
file-transfer.json
secure-storage.json

_Network Information and Call/Message Management_
contacts.json [2]
telephony.json
network-info.json
messaging.json

_Payments_
in-app-billing.json
purchase.json

_Webview_
webview.json

[d4n1]

I like it. Because it makes the most simple and clear document.

[nrooney]

Cool thanks! Also - should "Core Device, Task Management and Scheduling (Service?)" be "Performance Tuning" @dontcallmedom

[leandromsales]

                                                                                  What is the reference [2]?                                                                                                                                                                                                                                                                                                                                        Sent from my BlackBerry 10 smartphone.                                                                                                                                                                                                                From: Natasha RooneySent: segunda-feira, 25 de maio de 2015 08:17To: w3c-webmob/web-api-gapReply To: w3c-webmob/web-api-gapCc: Leandro Melo de SalesSubject: Re: [web-api-gap] New API Document Structure (#6)Cool thanks! Also - should "Core Device, Task Management and Scheduling (Service?)" be "Performance Tuning" @dontcallmedom 

—Reply to this email directly or view it on GitHub.

[dontcallmedom]

"Core Device, Task Management and Scheduling (Service?)" seems to match what is under "Application Lifecycle" in the roadmap doc at the moment @nrooney

[nrooney]

Application Lifecycle is good with me!