The April 2007 face-to-face meeting of the DDWG took place in Darmstadt, Germany at the offices of T-Online. It was attended by active participants of the DDWG, some invited members of the BPWG and other observers and was co-located with meetings of the BPWG and POWDER group over a five day period. This summary covers the initial DDWG-only meeting, the half-day joint meeting between DDWG and BPWG, the half-day session on structures and the full-day session on the initial designs for the API. The complete list of attendees is given at the end. Action identifiers are given for internal cross-referencing.
The week of meetings opened with a round of introductions from the DDWG members, new and old, and various administrative matters. As a reminder to existing members, and education for new members, the details of the various W3C publication resources were outlined. A poll shows that a large majority were familiar with the wiki mechanism.
Several open actions were reviewed and updated. The group have agreed a definition of “device description”, which will now be communicated to the UWA group [Actions 21 and 29]. However this is only an interim definition as more work has been done since the first definition was published on the wiki. The group is also engaged in reviewing the material from the recent OMA liaison statement and the status of this work is being communicated to the OMA directly [Actions 23, 24 and 30].
There was some debate around the form of OMA publications, which are generally compressed/proprietary formats not guaranteed to be compatible with Web browsers. The group cannot publish a transcoding of such documents to make them more accessible, but DDWG will raise the matter with the OMA. Meanwhile, PDF versions are made available internally.
The ontology files are now placed into the hands of the new UWA Working Group. The files currently in the DDWG wiki will be marked as archival, with a link to the active documents in the UWA [Action 31].
The process of getting public contributions for the DDR Core Vocabulary was discussed in detail. A Web form was considered, as was a pro forma email. The group decided to test a simple process internally first. This would determine what is needed to enable contributions, and how such contributions would affect the ontology maintained by the UWA. Having tested the process, it shall be launched in public. To demonstrate the process in public, the DDWG members shall submit in public some contributions based on the Top N results. Other groups will also be encouraged to submit contributions. A public mailing list to discuss such contributions may also be set up [Action 28].
The debate regarding the difference/relationship between the ontology and the vocabulary continued during the day. An illustration was proposed where the ontology would capture concepts such as Landscape and Portrait while a particular vocabulary might include a term to indicate if a device can switch from Landscape to Portrait. In this example, the vocabulary is referencing the concepts defined in the ontology. Indeed, it is agreed that everything in the ontology derives from the requirements of the individual vocabularies. Three of the members were actioned to draft a summary for publication on the wiki [Action 34].
The group also found fault with the use of the terms “static” and “dynamic” in the context of device properties. To avoid further confusion, it was proposed that the terms “class properties” and “instance properties” be considered instead. It was generally accepted that getting the terminology right would be non-trivial, but essential to avoid future ambiguities or confusion.
Before breaking for lunch, the group returned to the issue of the DDR Core Vocabulary public contribution process and formally resolved to test the process internally before opening the process to the public, starting with a blank vocabulary to which the DDWG would contribute from the Top N results.
After lunch, the group reviewed the existing public contribution process of the WURFL project. The process is lightweight, and relies on direct involvement of the primary editors. Patch files can be submitted to extend the collection. Objective information is easy to incorporate, but subjective information can raise issues.
The possible criteria for accepting a contribution into the DDR Core Vocabulary were discussed. There was some concern that a property may be added to the vocabulary without considering the complexity of obtaining such information. There would be no point in having a core vocabulary if the information to back it up was not available. This will be a topic for later discussion.
It was generally agreed that the core vocabulary should be small (i.e. restricted to essential items). From previous work of the DDWG, and experience of group participants, a figure of around 10 properties might suffice as a core vocabulary. If there are any other properties that might seem useful, but not essential to the goal of the DDWG, then perhaps these could be suggested for inclusion in vocabularies of other groups. With this in mind, the group resolved that “core” means the Top N plus some others that may come from public contribution (if there is a compelling case). In this way the entire vocabulary is a public contribution, bearing in mind that the Top N resulted from a public questionnaire during the group’s previous charter.
Other open issues were dealt with during the course of the afternoon. The issue of Naming Conventions remains open for further debate [Issue 1]. Keeping the OMA informed of the group’s work is an open issue, and remains this way as a reminder to maintain a healthy liaison with the OMA [Issue 2]. An issue with the OWL-DL vs OWL-Full was resolved when some minor issues with the file structure were identified and corrected [Issue 3]. A similar problem that was causing the DIG reasoner to generate warnings was also corrected [Issue 4]. An issue with the use of the enumeration pattern and/or the value-partition pattern was resolved through a resolution to use patterns representing closed sets of values when appropriate [Issue 5].
To close the day, a long discussion of the recent updates to the Requirements document ensued. The updates were mainly some minor rewrites and grouping of related requirements. The updated text avoids making any technical requirements on DDR implementations. There was some debate as to the general nature of the DDR that would result from successfully meeting the requirements. Most agreed that conformant implementations would be able to communicate with clients who require device information, and that it would be possible for individual DDRs to communicate with each other, which raises the possibility of them forming a network (if that is the wish of those who administer the instances).
A typical query against the DDR via the API is a request for the “value” of a “property”. The requirements mandate that the API must be capable of realisation as a Web Service. Whether or not an individual implementation actually provides a WS interface is a decision for the implementer. Nevertheless, it was accepted that in order to test the API it will be necessary to have at least one implementation that provides a compliant WS interface. It was also noted that by insisting a WS interface is possible, the requirements were also suggesting that it must be possible to interact with a DDR via HTTP.
Some of the requirements in the current document relate to expected behaviour of a DDR, while others refer to the characteristics of the API itself. This will need further clarification in future versions.
The role of the ontology in the requirements was also discussed. Providing an interface that is compatible with the ontology was seen as an important requirement. Mandating that the DDR must store all data indicated by the ontology was not seen as a requirement.
The issue of versioning was also discussed. Does the concept apply to every datum within the DDR, or to collections/classes/families of data? A fine-grained versioning system might be too much of an overhead, but this is an implementation issue. The issue had been raised in the 2006 workshop and was of some concern to people who rely on versioning as a quality aspect of their solutions. It was pointed out that if versioning information is not exposed in the API, then versioning should not be part of the requirements.
It was felt that the requirements should suggest the behavioural expectations of the DDR. For example, the requirements should not only indicate that a Put and Get method should be available, but that a Put followed by a corresponding Get will retrieve the data previously Put. If versioning is added to this description, then multi-threaded considerations might also be part of the requirements. For example, consider what happens when a Put occurs on a separate thread before a Get can retrieve the data inserted previously in its own thread. This is the problem of “data volatility”. The degree of behavioural prescription expected of the requirements was left as an open issue to be discussed at a later date.
While the Requirements document is being reviewed, work on the API itself will continue. The general thrust of the requirements has already been established in its first published draft. The revision is not expected to make any radical changes. Therefore the API work will be allowed to progress in tandem. Some members voiced concerns that a deep review of the Requirements document could delay the design of the API itself. Nevertheless, an agreed set of requirements is necessary. If necessary, the simultaneously developed API can be reviewed in light of any significant and unavoidable changes that might occur in the requirements.
Within the requirements there is the implied concept of device identity. The group is chartered to consider the distinction between the physical device and the software browser (user agent) hosted therein. It is expected that the API to the DDR will use a key to identify the physical device and/or browser. The variable nature of software (and now hardware also) means that this key may be a more complex element of the API than was originally expected. Several participants remarked that assigning an identity to a device, and subsequently recognising the device, is an ongoing issue for them. For the purposes of the DDWG, recognition will be restricted to aspects of the hardware/software of the Web-enabled device. Other characteristics of the delivery context, such as the capabilities of an interim proxy, are out of scope. In use, it is expected that the DDR will supply information about the client device, which can then be supplemented by information about the rest of the delivery context (but not the responsibility of the DDR). It was also noted that identity could be obtained via the HTTP interaction, but might also come directly from the user, or from the IMEI or similar serial number (together with an appropriate record that maps such data to the particulars of the device instance). An action was agreed to start a discussion on how one can identify a browser, device and other components [Action 35].
This concluded the first day of the DDWG face-to-face. Many of the issues discussed in this first day will be reflected in text to be published at a later date in the wiki and elsewhere.
In a three hour session, members of the DDWG and the BPWG met to share ideas.
In an effort to explain to the public audience how the W3C groups record their work, the raw minutes of this joint meeting are reproduced below. These minutes are entered in real-time by a volunteer participant on a text-based conferencing system, with other participants making corrections/additions, also in real-time. It is not a transcript. It is merely an approximate record that will be sufficient to indicate the background to any formal publications of the group. In this case, the scribes were Kevin Smith (Vodafone) and Cedric Kiss (W3C). The meeting commenced with the DDWG chair giving a summary to the BPWG members. (Note: some explanatory notes have been added [[thus]], some minor clutter has been removed, a comment of the form “Name:X” was entered by the scribe, while a comment of the form “<Name>” was entered directly by the named person.)
BEGIN – 09:00
<Rotan> Joint session to commence in a minute.
<Rotan> We're going to scribe this session on the DD IRC channel.
<Rotan> Kai is welcoming the participants.
<Andrea> Andrea Trasatti, M:Metrics and Invited expert
<jo> scribe: KrcSmith
Rotan [[chair DDWG]]: introduces Agenda
DD status
Rotan: DD have identified core usage of descriptions
... and priorities in the landscape and ecosystem
... led to first draft of Requirements to improve the landscape
... Then we rechartered aiming to produce an API definition
... Misunderstanding that we will build a database
... Instead we are building a framework that can allow interoperable device descriptions
... among repository providers, and between organisations
... In 2nd charter we have fostered relations in W3C and to OMA
... In this charter aiming to avoid ambiguity.
... Currently any two repositories will not interoperate (different interfaces etc.)
... So we looked at the underlying vocabulary.
... From Semantic web we took the idea of an ontology (formal framework for describing knowledge)
... Rhys [[Lewis]] has done good work in starting this ontology
… Using Protege tool to visually manipulate RDF/OWL
... However simplification can reduce functionality.
... So we have been testing an RDF/OWL framework using UAProf to test against
... Now we can work with relationships in UAProf and see results
... Next, need to see what information will be in the ontology/vocabulary.
... Need to see how to build vocabulary, will do this in member-only space first
... and then publicise. Will start with a set of proposed properties.
... Likely that others will propose items for vocabulary (and thence ontology).
... Vocabulary items have names, definitions, values, cardinalities.
... All of this needs to be represented in the ontology and vocabulary.
... Default values may be important for the vocabulary
... so would model those in the ontology and let the vocabulary refer to that.
... Important that the ontology definitions can be reused amongst users of the ontology.
... This is the strength of the ontology (commonality of concepts).
... Cedric [[Cedric Kiss, W3C]]to build web form for submissions, need a feedback mechanism and submission mechanism.
... Ontology to be honed in UWA WG. For reference by internal and external groups.
... Likely to continue work after current DDWG charter, so hope that value will be clear and work/process will persist.
... Also, finishing off other documents. Requirements is being overhauled to allow API definition to start.
... API is to provide interface into repository.
... API takes datatypes from vocabulary. Also need a definition of behaviours (e.g. versioning, querying)
... We will not detail the architecture.
... Will describe interface expectations.
... Interface will inform requirements and vice-versa.
... Interface will be defined in IDL.
... This provides mappings to other languages.
... Mandatory mapping is a Web service interface (i.e. it will be possible to implement a Web service interface).
... Also allows creation of Java, C etc. interfaces.
... We will provide a normative Web services definition of the interface.
... Now to drive awareness and ensure public confidence in the work.
... Working in public - first DD charter was member-only.
... Initial work could be seen as exposing sensitive data (commercial methods around device descriptions).
... DD was not attempting to expose the high-end commercial methods, but rather the basic information.
... This basic information was being gathered in multiple ways.
... Motivation was to allow mobile Web access to be as easy as fixed Web access.
... Stephane Boyera's [[W3C]] evidence showed all providers were experiencing same problems around device descriptions.
... Second DD Charter is Public for technical work (although any work can be member-only)
... We try to minimise member-only work. Can move items to member-list if contentious and then back to public when resolved internally.
... Minutes of meetings are blogged, and our documents are in a Wiki for public view.
... Wiki allows for inline change tracking which shows diffs inline.
... Diff can be made between any two Wiki versions of a document.
... Intention is to create xmlspec (W3C format) automatically from Wiki
DKA [[Dan Appelquist, chair BPWG]]: Like to focus discussion on BP requirements for core vocabulary.
... suggest we look at use cases (content developers using description data to achieve mobileOK)
... BP need to discuss public/private.
... can we really generate docs from Wiki?
Rotan: using Wiki inclusion mechanism to build the document.
... Pubrules [[W3C Publication Rules]] are enforced.
DKA: Would like to use those Wiki/documentation techniques in BP.
... Community process?
Rotan: Expectations for contributing data.
... Community process should be the way to contribute.
DKA: From developer perspective, if something is missing from core vocabulary? Inner core, outer core?
Rotan: Expectation is that approved properties will appear in the core.
... If we create a core with e.g. screen width, there is a likelihood that the screen width information will be available.
DKA: IF we require decisions based on device property which is not in the core vocabulary, then we have a problem.
Rotan: There will be commercial and open source implementations going beyond the core.
<Zakim [[Automated meeting system]]> jo, you wanted to suggest that we look at the top-n now
Jo: Suggest we show top-n properties
DKA: Would like to map BP use cases to top-n
Rotan: Wiki contains a top-n page.
... (rotan brings up email from Nov 2005 with top 5 [[the public questionnaire results]])
... 11, not 5, properties, because we had a member/public call for priority properties.
... Stephane [[Boyera]] weighted these and the result was a top 11.
Rotan: First (most important) was Screen dimension.
... At least one comment was that width was the most important part (due to Western language orientation and scrolling)
... This top-n will guide our initial contribution to the public vocabulary.
DKA: Suggest we take a view that Mobile OK basic tests can be fulfilled through device description data in core
... so need to go through those tests and see if core vocabulary can support them.
Jo: Think it's more useful to look at best practices (not Mobile OK), especially clauses about support
DKA: from developer perspective, how to conform to mobile OK basic - doesn't require any device information.
... but if I also want to script, use cookies, then that needs support from device descriptions.
Rotan: MobileOK does not assume access to device information.
... So not best practice, or mobile OK as it currently stands, but what information does MobileOK most want to know.
DKA: Don't want to reinvent MobileOK - since we have MobileOK basic, people will want to know if there is a mapping to device information.
... Must ensure public do not identify a split.
Ed: +1 for Rotan - i.e. MobileOK + device information
Rotan: MobileOK is distinct from device information, but want to make information available to MobileOK and see how it affects MobileOK (e.g. for charter 3)
DKA: I don't disagree :)
<Zakim> jo, you wanted to say that if we had spent as much time looking at the document, as opposed to discussing which document to discuss, we'd be half way through one of them by now
Jo: Stop discussing what to discuss :)
Rotan: propose we start with MobileOK and assume we have information available. How would that change the MobileOK requirement.
Determine device information benefit to MobileOK requirements
DKA: (going through Mobile OK tests)
... starting at 3.1
Jo: may want to capture how device supports HTTP 301/2 redirects
DKA: this is granular
Rotan: Core vocabulary cannot target very specific information
... Auto-refresh is very narrow focus.
Jo: Suggest this be an information gathering, not evaluation, session.
DKA: 3.2 Caching
... correct use of HTTP caching directives, cannot see a device information need?
Rotan: +1
DKA: 3.3 Character encoding
... UTF-8 support should be in core vocabulary
<Kai> +1
Jo: believe we want to know supported and preferred character encodings.
<Kai> to Jo's point
Rotan: so a list of preferred encodings?
Rhys: we have these lists in the example ontology.
DKA: 4 Content format support
Jo: suggest again list of supported/preferred media types
Rotan: Nice to know in advance what device supports.
Jo: Must be careful as there is an opinion that accept headers must prevail
DKA: so support for JPEG, PNG, SVG?
Jo: SVGT
Rotan: also granularity (GIF vs animated GIF)
Jo: CSS support
Rotan: what level of CSS?
DKA: what CSS feature set.
Rotan: can say version of CSS supported, and to what level the device conforms to those specs.
MikeSmith [[W3C]]: for UTF-8, if we don't know what device supports you produce UTF-8?
DKA: Yes
MikeSmith: not the case for Japan, Korea (Shift-JIS etc)
... should not prescribe the default
<Zakim> MikeSmith, you wanted to talk about UTF-8
<Zakim> Kai, you wanted to ask if it is a good idea to worry about faulty implementations by vendors, rather than saying that a spec should be supported
DKA: UTF-8 has been extensively debated. May need to extend requirement for Asian defaults.
Kai: Should only support CSS version support, not granular features
Rotan: W3C has been prescribing CSS support
Jo: (reiterates need for gathering not evaluation).
... +1 to Mike's comment about Asian UTF-8 default.
<Zakim> MikeSmith, you wanted to address conformance checking
<Rotan> The reality is that many (mobile) browsers only support a subset of CSS, and that's unlikely to change any time soon. So to create content for these devices, it's better to know what subset they support, rather than just knowing that they do/don't support CSS.
MikeSmith: need conformance checker to align with reality
DKA: suggest move this topic to BP meeting, especially as regards Korean work in this area.
... 3.5 Default Input Mode
... Important, if you know device has QWERTY keyboard may want to offer a more sophisticated form (and warn otherwise).
... if we assume something is supported we don't need it in core vocabulary
Jo: Tests show no device supports input mode
Rotan: If you knew something in advance it changes your tests/recommendations.
DKA: 3.6 External Resources
... should we look at memory size?
Jo: this is to ensure page loads in reasonable time.
... may want to know connection.
Rotan: so is this a DDR property, or a variable/dynamic property which cannot be retrieved from DDR API
Jo: Current load of bearer is dynamic
Kai: bandwidth + device is a composite
Rotan: Maximum bandwidth capacity may be a useful 'static' property
DKA: notes 3.7 and 3.8 have no impact on DD vocabulary
... but will a pointing device affect image maps support?
Jo: not supported in markup is a useful property
Rotan: may be combination of markup support and pointing device and map complexity
... so test suggests input mode, markup support for DD vocabulary
DKA: presence of pointing does not prescribe method.
Kai: are we all aware of DDC (Default Delivery Context) as regards BPWG
Rotan: we are asking what to do if you know something about device (i.e. not use the DDC)
DKA: 3.9 Image Resizing/Specify Size
Jo: need width, height and possibly shape
DKA: 3.10 Link Target format
Jo: Same issue about character encoding
DKA: 3.11 and 3.12 are not device specific
... 3.13 No frames
... may be useful to know if device provides a frames experience
Jo: And how sensible it is. What frame behaviours for IFRAME.
Rotan: should know if device supports frames and then choose to use accordingly. Edge cases where frames are supported if done properly.
DKA: technical decision because mobile browsers don't usually have pointing device
<jo> [pop up support and Object support of html media (iframe equivalent)]
Rotan: but PDA's with a stylus. Can calculate if it will be reasonable to support frames (markup support, screen, pointer)
DKA: developer will want to know whether to use frames version or not
Rotan: which could be a stylistic decision
<Zakim> Kai, you wanted to speak of frames and bookmarking
Rotan: i.e. it's subjective. Core vocabulary should not have subjective decisions, but can inform subjective decisions through objective information
Kai: Problem with bookmarks and frames. In future XFRAMES can help this. IFRAMES are important for us, so markup support important
<Kai> ....and to be able to use iframes if we know the device supports it.
Jo: Up to user to decide whether to use based on objective information available.
Rotan: objective information can be tested, validated. Subjective information differs, difficult to populate vocabulary with this.
DKA: 3.14 Non-text alternatives, no impact
... 3.15 Obects or script
... to what level of detail do we need to know object, script support.
Rotan: Big question. Historically script version support has been important. Lots of potential properties (max. threads, etc.).
... AJAX community may take this on board.
DKA: Center for handheld Web (RIT) have non, basic, advanced JavaScript support categories.
... advanced includes XHR, basic does not.
... We could adopt these categorisations for the vocabulary
Jo: So can note that the information is required. And note support for Objects.
Rhys: Disagree following AJAX for script support
... level of libraries available is another factor.
DKA: Not suggesting AJAX support for core vocabulary
Rhys: Advanced Javascript not same as AJAX
DKA: Sounds like a charter 2 discussion.
Rhys: Javascript, yes/no; AJAX, yes/no
Jose: DOM implementation support? How does the Javascript/ECMAScript support it? Important for developer
<Zakim> MikeSmith, you wanted to muddy the waters further
Rhys: agree, this is an example of what I was saying that we need to detail Javascript properties.
MikeSmith: +1 to Jose, Rhys. More factors than just 'support Javascript'
DKA: Agree that granular info is useful, but for a developer what will they realistically want to know in order to improve user experience. Don't want to make it too abstract
... Useful to able to aggregate this information into a few profiles (broad support vs granular).
Rotan: +1. Scripting, dynamic features are an application space. Best to discuss in UWA.
Rhys: Should be able to derive 'advanced' support from a composite of the granular features.
<cedric> scribe: Cedric [[Cedric takes over from Kevin as scribe]]
3.16 Page Size Limit
Rotan: a big page is confusing for the user; many images are a problem for browsing speed
... is the motivation for the device or end user?
... DCCI is the framework in which one can query which is the memory limitation
Pavel: some just cut data after some predetermined size
Jo: Motivation for 10k was an ergonomic point but the 20KB limit was a memory size one
DanA [[DKA]]: even fancy browsers on fancy devices can reach the memory limitations
<inserted> 3.17 Page Title - nothing to say
<inserted> 3.18 Pop Ups it would be useful to know if the device is capable of opening a secondary window
3.19 Provide Defaults
DanA: Makes it easier to navigate forms. Don't think we need anything with the Core Vocab on this one
3.20 Scrolling
DanA: Don't think we need to look further.
3.22 Style Sheets Use
DanA: Nothing to add
3.23 Tables Alternatives
DanA: In general it might be useful the limits to the support of tables
... (max number of columns, etc.)
Rotan: It's difficult to get that information because not many device manufacturers will share this data
3.26 Valid Markup
Rotan: On some devices, certain valid markup syntaxes may crash the system
Jo: I think it would be good to make a tour of some of the BPs
Rotan: Fonts are an interesting one
DanA: shall we do a quick tour?
<jo> (note deficiencies could lead to a large number of properties)
Jo: do we need something about max length of the URIs?
<Kai> Here is the input I had obtained what we need to know for content adaptation
<Kai> Content type if different than the markup used
<Kai> Encoding if different from the markup used
<Kai> Maximum images size
<Kai> Screensize
<Kai> Screen orientation (vertical / horizontal)
<Kai> Imageformats
<Kai> Input means (keypad, touchscreen, wheel, pen, mouse, joystick, ...)
<Kai> Fonts and sizes, so the max. number of characters per screen width can be calculated
<Kai> Scripting and versions (ecma script 1.0, 1.1....)
<Kai> CSS possibilities and what can be used
Andrea: there might be limitations but unless it's over 300 characters, the real issue is in the user-friendliness of the URI
Jo: I don't disagree but we may need to capture the idea that there might be such a limitation
Andrea: 255 is still a fairly long URI and modern browsers support much longer
Normen: is there any typing assistance indication?
... such as T9 or whatever. Is it relevant?
... if there are certain domain names or TLDs pre-populated,etc.
DanA: I suppose the best cases are around scripting and CSS support
... so we need to have an in-depth discussion
... do we need to use a specific CSS profile depending on the device capabilities
Rotan: This joins the discussion about should we consider support of subset of specifications
<Rotan> How browser device supports 301/302 redirects.
<Rotan> Supported and preferred character encodings.
<Rotan> Preferred content formats (apart from Accept header info).
<Rotan> Elaboration of supported content format (e.g. GIF *with animation*).
<Rotan> Level of CSS support/compliance.
<Rotan> Default input mode (keyboard, stylus, tab/shuffle).
<Rotan> Bandwidth capability (limit).
<Rotan> Support for image maps.
<Rotan> Support for frames (i.e. Frames, IFrames, XFrames).
<Rotan> ECMAScript, JS-Library support, Interfaces accessible from JS etc.
<Rotan> Intrinsic events supported by browser.
<Rotan> Memory capacity of browser.
<Rotan> Ability to open a secondary window.
<Rotan> Table support limits (rows, columns, nesting etc.)
<Rotan> Fonts, defaults sizes, support for effects etc.
<Rotan> Colour depth.
<Rotan> Support for cookies.
<Rotan> Maximum length of URIs.
<Rotan> Presence of typing assistance (e.g. T9).
[Rotan pastes his quick list of 19 properties]
Center for the Handheld Web [[Presentation]]
DanA: "Taking your website mobile" is an interesting presentation
... created in the Center for the Handheld Web
... I've been in contact and asked him to joined the group
... they have similar guidelines as the ones we developed regarding MIME types
<MikeSmith> http://chw.ariadne.mobi/presentations/2007_OxfordFutures/goingDual_short.html
<MikeSmith> http://chw.ariadne.mobi/presentations/2007_OxfordFutures/goingDual.html
DanA: the interesting bit came around the JS support level
<edm> There is also a PDF of these slides at http://chw.ariadne.mobi/presentations/2007_OxfordFutures/goingDual.pdf
DanA: support for XMLHttpRequest and AJAX (Advanced)
... I really think we should make statements about what is a basic/advanced support in the UA
... same for CSS combined with media types
... they make some work similar to what we've done
Jose: why are you calling it the handheld web?
DanA: it's actually about the mobile web
<MikeSmith> [we leave for demo, then lunch; back in 60 minutes prolly]
END – 12:00This concluded the joint meeting between DDWG and BPWG. Readers will note that the raw minutes format can actually be quite long, which explains why the DDWG publishes meeting summaries instead. The two groups retired to lunch following this three hour joint meeting and at 13:00 the DDWG continued with its own meetings.
The afternoon commenced with a demonstration of the use of Protégé to edit ontology/vocabulary files. It was agreed that some screenshots of this demonstration would be made available later. Over a period of an hour, the group followed a working example, some involving material being edited by Rhys as part of the UWA’s ontology resources. Some questions were raised, such as how to create/use references from one Protégé project (e.g. the core vocabulary) to another project (e.g. the UWA ontology), in order to create a stand-alone document. Other questions related to the use of cardinality, the role of aliases, the role of embedded comments. Through this hands-on session, the group increased its familiarity with the visual tool, which will be important as the core vocabulary comes together.
After the Protégé demonstration, the group returned to the difficult issue of “device identity”. The problem is about applying a label (identifier, or key) to something that corresponds to a “Web-enabled mobile device”. In the early days, a physical device came with a pre-installed browser, and this pairing did not change. In such a case, a single identifier would suffice to unambiguously identify the Web-enabled mobile device. This identifier could then be used to reference a set of properties. The world has since moved on, and now we have devices whose physical characteristics can be modified, and whose software can be changed at will. The various identifying mechanisms (e.g. the UA header of the browser) can identify the hardware, the software or both to varying degrees of accuracy. Finding a single mechanism to uniquely identify any particular Web-enabled device in this highly volatile environment is proving to be difficult.
It may be possible to identify individual components of the Web-enabled device, such as the firmware, the screen, the browser, the physical input modes etc. This would be a considerable task for a repository maintainer, and it is unclear if a dialogue with a device would actually reveal the various components. Currently, the HTTP headers barely identify the browser and the device model. In some cases, only the browser is identified. Many commercial implementations rely on other clues to aid identification.
One technical solution, though probably infeasible without an ongoing commitment of resources, would be a registration authority that would record each new device as it is launched/discovered. Alternatively, the key could be derived from (some of) the characteristics of the device to be recognised. After discussing the issue carefully, the group resolved that the DDR key should be a compound key, which would involve both hardware and software identifiers. It was decided that the nature of the constituents of the compound key would be discussed later [Issue 9].
The group then went on to discuss another form of identification: that of families or groups of devices. To gain an understanding of the complexities, the five use cases currently on the public wiki (http://www.w3.org/2005/MWI/DDWG/wiki/DeviceDescriptionStructuresUseCases) were discussed in detail. Use case 1 dealt with the problem of associating a tabular layout for devices classified as PDAs. This might be resolved by defining a virtual device called a “PDA”, against which any candidate device could be compared to determine if it meets the criteria. Use case 2 dealt with the sharing of a definition, so that others may benefit from the classification. This suggested that a common representation for membership criteria may be necessary. Use case 3 reinforced this view, and also raised the issue of overlapping definitions (e.g. when is a Smartphone a PDA?).
It was clear at this point that the representation of device families (groups) would require an expression language in order to formally define any labels such as “PDA”. One could apply the expression to all devices recorded in a DDR and store the result against each entry, or one could execute the expression at the time when a query is made. However, this might also introduce some processing overheads and security risks (e.g. making a series of requests using complex family expressions that consume excessive CPU time). While it is not the remit of the group to get into implementation details, it is natural to be concerned about such matters.
It was proposed that JSON might be a candidate expression language that would be simple enough, yet sufficiently expressive, and fairly familiar to developers. An action was recorded to investigate JSON and report to the group.
Use cases 4 and 5 dealt with the use of device families for the development and provisioning of mobile applications, in order to record compatibility with various operating platforms. This may be useful where application vendors claim compliance with certain platforms, and are forced to re-test whenever a new model of device is launched in order to support the claim. In contrast, a claim of compatibility with “Mobile Operating System XYZ” is easier to make when the test only requires a representative sample of the device family that corresponds to OS XYZ.
The group agreed a few minor adjustments to the Structures document. The Terminology section would be moved to the Introduction, a Structures API Bindings would be added, and the Conclusions removed (as this is not an analysis document).
It was noted that the other two documents in the wiki (Landscape and Ecosystem) had reached a point where all of the original material was completely recorded, and that minor updates were now taking place.
The final day was dedicated to initiating the API design work, with a focus on the issue of the key that would be used in the various Put/Get operations.
It was resolved that the binding mechanism for the API would be external to the API definition. The use of IDL to specify the API should ensure that adequate binding mechanisms will be available.
The group went through many possible keying techniques. It was eventually decided that a key would derive from the hardware and software characteristics, that this key would be used in a Put operation, together with an identifier of the property and the value to associate with that property. To retrieve the data, the parameters obtained from a recognition stage (not covered by the API definition) would be used to generate the key, and then used in a Get operation.
One possible idea is to specify the key generation algorithm for use with the DDR Core Vocabulary. The algorithm would be based on detectable signatures (e.g. the HTTP headers). This will need further investigation.
Near the end of the day, the group rejoined their BPWG colleagues to discuss matters relating to the new charter for the BPWG.
Some members of DDWG remained beyond the conclusion of the DDWG meetings in order to participate in the co-located BPWG and/or POWDER meetings.
The DDWG chair extends special thanks to the hosts, T-Online, for providing an excellent venue.
This is the complete list of people who attended one or more of the various meetings.