Feature-based Device Description and Content Annotation

1. Feature-based Device Description and Content Annotation Alamgir Farouk

2. Defining our scope Generalizing X-Independent content X-specific content Where X = device, network (2G, 3G), context (time, location, transaction) etc. The transformation or specialization can be done • at server during content generation, developer fully responsible • en-route automatically or with hints from developer • at client automatically, or using hints or embedded scripts, which are again responsibility of the developer There are many aspects of this problem ! We address one small part !

3. 'Evolution' and Features • The issue: Devices (hand-held and others) are evolving! • Key to our proposal: Acknowledging and accommodating this evolution • Evolution occurs by (simplified view) • Existing characteristics or features (variables) vary • New characteristics or 'features' show up • Old characteristics or features stop varying or disappear • Identifying a 'feature-set' is then very important, -it makes the system evolution-tolerant yet evolution-compatible.

4. Features-based Device Description • Define features so they form a comprehensive 'set' • Define features which are still varying • Discretize the possible values these features can take (developer-friendly) • Describe device in terms of values of these features. • Use this feature-set to create Device-independent Content

5. Defining Features

6. ‘Values’ of Features

7. "Space"

8. Only some points are ‘real’

9. Current phone set is subset of P

10. ‘NEW’ Feature is added

11. Extending the ‘SPACE’

12. Features become obsolete

13. 'Members' of the Phone' SPACE

14. 'Features' describing phones Device Features are mutually independent characteristics of the device. Together, they should completely describe the device. Example Name: Aspect Ratio of display Values: Landscape or Portrait (DISPLAY_LANDSCAPE, DISPLAY_PORTRAIT) (Full set of features not shown here)

15. Difference between UAProf, CC/PP and 'Feature' s Let us compare how the display screen is described by the two methods. UA Prof Feature Variables are X and Y Variables: Aspect-Ratio and Density X x Y (60x100, etc) Landscape and High X and Y are continuous variables. Aspect-Ratio and Density are NOT continuous variables. Developer must deal with infinite Developer deals with finite possibilities. possibilities. Some variables are going to be identical or similar, but otherwise they are not the same system of describing a phone (or device)

16. Phones with different aspect-ratios DISPLAY_PORTRAIT DISPLAY_LANDSCAPE …

17. Developer participation • Not ALL features require developer help or hints. For example, pixel aspect ratio, which can distort circles into ellipses, can be taken accommodated automatically. • Some features are irrelevant, for example screen-brightness, battery-life. • The rest require hints from the developer for the system to accommodate. • We develop a system to 'annotate' content based on the 'feature-set' chosen. • We close the loop using a 'Processor' which can match devices to feature-values and make content device-specific using this mapping.

18. Annotating content Motivation in choosing implementation method: • Use existing markup language if possible • Meta-data being added should be backward compatible • Simple 'english-language' words. • Practical, should not be difficult to implement. Result : Use 'class' attribute of WML, which is ignored by the browser, but supported by EVERY element. So far we have not been surprised!

19. WML Content Sample with meta-data <wml> <card> <table class="DISPLAY_LANDSCAPE" > (….landscape table…) </table> <table class="DISPLAY_PORTRAIT"> (….portrait table…….) </table> </card> <wml>

20. Feature value and annotation match-making • On one side: • Content in standard WML with embedded feature specific meta-data. • On the other-side: • Devices with different physical characteristics. We act as the match-maker, -mapping device characteristics to features, and modifying content based on annotation. Feature Value example: If the feature Aspect-ratio is termed a Nokia7110 a = DISPLAY_PORTRAIT (a = A) R380 a = DISPlAY_LANDSCAPE (a = A)

21. Content Modification We have to modify or filter the content based on 'current' feature list of 'client' device. Our Approach: • Parse serial content into Document Object Model (DOM), • Manipulate the DOM based on Meta-Data and Feature (filter or modify), • Serialize the DOM back to output stream. Sdfasdf asfdasfdasf Asdfe ewewewe flakjlkfi Asflfaldsklk oioweewfe jklaasdas jfkajlkf faefa lkf Flkajwlekfjlakjlekjflawkejflaw lakwelaskdfasdfasd Af fw wlkelkkjflklajlkjj Sdfasdf asfdasfdasf Asdfasfdasdf asf asdf asdf Asdfasfd asdfasdfasfd asdf Asdfasdf asdfdasd asdfasdf Asdfasff asdfasdf asdfasfd Asdfadsf asdfasddf a a

22. Advantages and Limitations • LIMITATIONS • Applications will need to be updated, and will need a minimal filtering to work. • Significant involvment of application developers (i.e. not automatic) • Mappings must be updated when new devices are released or features are defined • Agreement or standard required. • ADVANTAGES • Decouples devices and developers, allowing each to innovate independently • Allows for advance release of features by device manufacturers • Allows application developers to incorporate features in advance of device releases • A practical compromise as opposed to an absolute yet unattainable ideal

23. Conclusion • We proposed a method to describe devices in terms of 'features' • They are 'evolution' compatible. • Their values are 'developer-friendly'. • It is a compromise, • We sacrifice 'fine-grained' device specialization • We gain 'simplicity' and 'longevity'. • We achieve device-independent content generation by requiring developer to be 'aware' of device features, but not actual device. • It will only work, however, if 'features' are chosen judiciously and everyone agrees on a standard.