Featurebased 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

• ltwmlgt
• ltcardgt
• lttable class"DISPLAY_LANDSCAPE" gt
• (.landscape table)
• lt/tablegt
• lttable class"DISPLAY_PORTRAIT"gt
• (.portrait table.)
• lt/tablegt
• lt/cardgt
• ltwmlgt

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.