Feature-based Device Description and Content Annotation Alamgir Farouk

Feature-based Device Description and Content Annotation Alamgir Farouk 1 © NOKIA 2000 Feature. Based Device Description and Content Annotation

Defining our scope Generalizing X-Independent content X-specific content Where X = device, network (2 G, 3 G), context (time, location, transaction) etc. The transformation or specialization can be done 4 at server during content generation, developer fully responsible 4 en-route automatically or with hints from developer 4 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 ! 2 © NOKIA 2000 Feature. Based Device Description and Content Annotation

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

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 (developerfriendly) • Describe device in terms of values of these features. • Use this feature-set to create Device-independent Content 4 © NOKIA 2000 Feature. Based Device Description and Content Annotation

Defining Features 5 © NOKIA 2000 Feature. Based Device Description and Content Annotation

‘Values’ of Features 6 © NOKIA 2000 Feature. Based Device Description and Content Annotation

"Space" 7 © NOKIA 2000 Feature. Based Device Description and Content Annotation

Only some points are ‘real’ 8 © NOKIA 2000 Feature. Based Device Description and Content Annotation

Current phone set is subset of P 9 © NOKIA 2000 Feature. Based Device Description and Content Annotation

‘NEW’ Feature is added 10 © NOKIA 2000 Feature. Based Device Description and Content Annotation

Extending the ‘SPACE’ 11 © NOKIA 2000 Feature. Based Device Description and Content Annotation

Features become obsolete 12 © NOKIA 2000 Feature. Based Device Description and Content Annotation

'Members' of the Phone' SPACE 13 © NOKIA 2000 Feature. Based Device Description and Content Annotation

'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) 14 © NOKIA 2000 Feature. Based Device Description and Content Annotation

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 Xx. Y Landscape and High (60 x 100, etc) X and Y are continuous variables. Aspect-Ratio and Density are NOT continuous variables. Developer must deal with infinite Developer deals with finite possibilities. Some variables are going to be identical or similar, but otherwise they are not the same system of describing a phone (or device) 15 © NOKIA 2000 Feature. Based Device Description and Content Annotation

Phones with different aspect-ratios DISPLAY_PORTRAIT DISPLAY_LANDSCAPE … 16 © NOKIA 2000 Feature. Based Device Description and Content Annotation

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. 17 © NOKIA 2000 Feature. Based Device Description and Content Annotation

Annotating content Motivation in choosing implementation method: 4 Use existing markup language if possible 4 Meta-data being added should be backward compatible 4 Simple 'english-language' words. 4 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! 18 © NOKIA 2000 Feature. Based Device Description and Content Annotation

WML Content Sample with meta-data <wml> <card> <table class="DISPLAY_LANDSCAPE" > (…. landscape table…) </table> <table class="DISPLAY_PORTRAIT"> (…. portrait table……. ) </table> </card> <wml> 19 © NOKIA 2000 Feature. Based Device Description and Content Annotation

Feature value and annotation match-making • On one side: 4 Content in standard WML with embedded feature specific meta-data. • On the other-side: 4 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 Nokia 7110 a = DISPLAY_PORTRAIT (a = A ) R 380 a = DISPl. AY_LANDSCAPE (a = A ) 20 © NOKIA 2000 Feature. Based Device Description and Content Annotation

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 asfdasf Asdfasfdasdf asdf Asdfasfd asdfasfd asdf Asdfasdfdasd asdf Asdfasff asdfasfd Asdfadsf asdfasddf a a 21 © NOKIA 2000 Feature. Based Device Description and Content Annotation Sdfasdf asfdasf Asdfe ewewewe flakjlkfi Asflfaldsklk oioweewfe jklaasdas jfkajlkf faefa lkf Flkajwlekfjlakjlekjfla wkejflaw lakwelaskdfasd Af fw wlkelkkjflklajlkjj

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

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, 4 We sacrifice 'fine-grained' device specialization 4 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. 23 © NOKIA 2000 Feature. Based Device Description and Content Annotation