The DDWG held a face-to-face meeting in London on 16 and 17 July 2007, at the offices of Vodafone. Items on the agenda included:
The group resolved to publish the updated legacy documents (DD Landscape and DD Ecosystem), which were completed in public via the group’s wiki. The text of the documents will be restructured according to the W3C’s publication templates. The newly formatted documents will be placed into the W3C publication process at the end of August, following a final proofing by the group.
The wiki also contains other items of interest, particularly the ongoing research on IDL and IDL tools. It was decided that this material, when complete, should also be put into the formal W3C format and published as a Working Group Note.
The ontology being managed by the UWA WG is intended to comprise the vocabularies of various groups, including the DDWG’s DDR Core Vocabulary. There was some debate as to the way names in the ontology should be used. It was eventually concluded that the names (of properties) in the ontology must be unique, and that the UWA would oversee the ontology to ensure this is the case. These unique names should be consistent between the ontology and the vocabularies that reference the ontology. While it is possible to have different names for properties in the vocabulary, it makes more sense for the names to agree with those in the ontology. It is also possible for properties to be namespaced, in order to distinguish them from similarly named properties of unrelated concepts.
However, there was some concern over how the choice of names would be managed when there is likely to be more than one group developing vocabularies. To explore the issue, the group took to the floor armed with flip-charts and coloured pens. A “pixelWidth” property was used as an example. This could be a property used in a vocabulary related to images. It could also be part of a vocabulary related to digital camera. To distinguish them you need namespaces.
As a consequence of using namespaces, it is necessary to ensure that the DDR API supports namespaces when referring to properties by name. Furthermore, it was proposed that for an implementation that is using the DDR API for content adaptation, the default namespace should be that of the DDWG’s.
This idea was also considered as part of a discussion on the use of stateless methods versus stateful methods. If using stateless methods then references to named properties must include the namespace unless the DDWG default applies. In contrast, a stateful (session) approach would allow the default to be overridden for a sequence of requests to the DDR.
As vocabularies evolve, there will be a need for some versioning mechanism. It was agreed that namespacing should not be used as a versioning mechanism. The details of how versioning would be supported will have to be discussed at a later date.
When a user of the DDR retrieves a property by name (and namespace), what is returned? The group considered two main possibilities: a value, or a structure. In some cases, a simple value is appropriate, though it should at least be unambiguous in terms of units and other metadata (such as whether this is a default value). However, there are cases where a more complex structure might be of more use. For example, if one retrieves a value for “supportedImageFormats” it may make sense for this to be a simple (unordered) list such as [JPEG,PNG,GIF]. However, in this example, the presence of “GIF” in the list does not clarify if this means the GIF87, GIF87a or GIF89a versions of GIF (where the “a” versions support animation). It was decided that it should be possible to retrieve more complex answers, potentially as a single response that can be inspected, or as a sequence of interrogations where the user recursively refines the query to discover the specific information needed. For certain common cases a set of convenience functions may be appropriate.
Having discussed the use of names and namespaces, the group turned its attention to the use of the Interface Definition Language (IDL) to express the evolving DDR API, and to determine how such expressions would be represented in actual programming languages.
Because of the anticipated need to support IRIs, the group concluded that it would make sense to define a custom string type to use for data that may require IRIs (or any other cases where UTF 8 is appropriate). Other groups have done similar things for similar reasons, such as the DOMString type used in the DOM APIs.
If DDWG defines a DDRString type as an array of Unicode characters, the usual IDL mapping to programming languages would produce character arrays, even if a suitable native string type was available. It was therefore suggested that DDWG would also define mappings for DDRString. However, instead of prescribing a mapping for individual languages, the group would provide guidelines for mappings that could be applied to any programming language. In the case of DDRString, the guidance would say that this data type must map to a native type, or well established type, that represents UTF 8 strings. In the case of Java this would suggest DDRString maps to java.lang.String.
Then there is the issue of passing parameters and returning results to/from methods in various programming languages. Values can be passed by value, or by reference. Return values are typically scalar, so returning multiple values is accomplished either via a structured data type, or by modifying the values of pass-by-reference parameters. To understand the implications of these data passing approaches, the group considered a basic method: getProperty().
The getProperty method would obtain a value from a DDR repository. To do this, it must identify the property and optionally the namespace. The returned value should indicate if a known/measured value is being returned, or if a default is being returned. It is also possible that multiple values could be returned. The measurement units might be indicated as part of the input parameters, or as part of the returned value.
There are also different deployment scenarios for such methods. In a cataloguing scenario, there is much retrieval of data, including traversals of entire subsets. In an adaptive scenario, the data being returned depends completely on the context, and refers to a specific device, browser, network etc. These scenarios have different demands. The former requires expressivity and completeness, while the latter requires brevity, focus and efficiency. Consequently, it was suggested that the API methods may be categorised according to their expected usage scenario, as a guide to their design and subsequent implementation. The principles behind the design of the API would also be captured in the API specification document.
The issue of metadata, errors and exceptions was also debated. Calling a DDR API method should return a result (scalar or structured), but this result may be accompanied by metadata (e.g. units) and possibly a return code (e.g. “this is the default value”). There can be other types of return code to represent warnings/errors (e.g. “there is no value because while the property is known, a value for the current context is unavailable”) or exceptions (e.g. “there is no such property”). In general, the choice of representation of parameters will be captured in the IDL, together with the mapping guidance that will be included to enable implementation in various languages.
While it is the intention to be language neutral, the practical view is that the DDR API will be used by developers working with popular Web development languages. Therefore the mapping of the IDL should consider the needs and limitations of such languages. After a short debate, the group decided that a list of programming languages would be agreed, and that these languages would be considered during the design of the API. If a design decision causes issues for one of these agreed target languages, then the decision would need to be reviewed. Similarly, specific language benefits should also be considered, even if it means providing a custom mapping for the IDL. This was already indicated in the group’s discussion about the mapping of the custom DDRString type.
The group resolved to let the following languages guide the design of the IDL: Java, ECMAScript, Ruby, PHP, Python, PERL and the .NET family of languages.
Experiments on the sample IDL from the DDWG’s wiki revealed that the existing IDL tools generate a considerable amount of language-specific source files, even for the most simple input. The generated code is also overly complex. This poor result further supports the groups resolve to do things manually.
The possibility of using UML tools to design the high-level view of the API was considered, and some participants will now look for appropriate tools in this area. These tools might also provide the means of documenting the API visually.
The group resolved to have a first draft for publication by the end of September. Much of the IDL work would be done manually. There would be a mapping of the IDL to Java, also created manually.
Tools for generating WSDL from Java are mature, so it may be possible to automate the creation of a WSDL binding via a manually created Java binding. If the Java binding broad support, it may be made normative. The WSDL binding will be made normative. However, the specification will not demand that these bindings are present. Instead, if an implementation claims that it has a standard binding (e.g. in WSDL) then this will be taken to mean that it offers a binding as specified in the normative binding within the specification. Furthermore, individual implementations will be free to offer additional bindings, including alternative bindings in the same language (e.g. WSDL). Such bindings cannot be described as standard with respect to the specification.
Standard bindings are needed to support interoperability. With these in place, any client that implements the standard binding in any language will be able to communicate with any implementation of the DDR that also supports the standard bindings. It should not be necessary for the client and the DDR to be implemented in the same language.
The recently formed Context Key Taskforce of the DDWG reported that the context key (an object that identifies the context of a particular property from a device description) should consist of an unlimited number of identifiers referring to different aspects of the delivery context. Furthermore, it is for each individual implementation of the DDR to decide the actual composition of such a key. In the contexts considered by the DDWG, the context key would identify a browser and a device/platform.
Experience shows that different adaptive solutions use different evidence to determine the delivery context. Many, for example, use the HTTP headers from a request originating at a browser. Others may use custom device identifiers such as the MSISDN. Even the process of asking the user directly is a means of getting evidence to determine the delivery context. Because of the huge range of possibilities, no single context key mechanism is going to suit all scenarios.
After much debate, the group concluded that the context key must be considered as an opaque object, whose composition is locally defined, but for the purpose of being represented in the DDR API it should have some “type”.
The role of the context key is to represent the result of a recognition/discovery process that takes evidence (e.g. HTTP headers) as input. The context key can then be included in a request to the DDR to retrieve properties that are relevant to the delivery context as determined by the previous recognition/discovery process. The context key may be used again and again, though probably should only persist as long as a session.
It is certainly possible to consider an implementation where the context key is inaccessible to the caller. In such a situation, the caller provides contextual evidence and also the identity of properties to be retrieved. The returned result would be values for such properties, but not the context key itself. Indeed, in this case the context key may only be conceptual.
It is necessary for the recognition/discovery process to have a local agreement with the DDR so that the context keys created by the recognition/discovery process can be used by the DDR. Furthermore, this will also permit multiple DDRs to agree to use the same recognition/discovery process.
It was proposed that, for illustrative purposes, a recognition/discovery mechanism and corresponding context key based on HTTP header analysis would be described in the API specification.
Originally, the Requirements document focussed on the key characteristics of the DDR, as might be expected from reading the Landscape and Ecosystem documents. It described how it might be deployed, the administrative interface, security, trust and the basic I/O methods. As the DDWG moved into its second charter, it has become clear that two types of requirement will be needed.
First there are general criteria for assessing if a DDR implementation will fulfil the role that the DDWG expects. Second are the conformance requirements for any implementation of the DDR API. It was decided, therefore, that the API specific requirements currently in the Requirements document would be moved to a normative section of the API specification to cover conformance. This leaves the “assessment criteria” to the Requirements document, a Working Group Note that summarises the high level expectations regarding DDR implementations. These can also be used as design principles for implementers.
The Requirements WG Note is not normative. It is an informative document. Such a document cannot mandate the behaviour or other characteristics of a DDR instance. It cannot, for example, demand that a DDR contain a certain minimum number of entries. The document can, however, demonstrate how the DDR is used, via several use cases. These are already in the document.
With the move of normative conformance requirements to the API document, the current Requirements document will undergo another (final) iteration to focus on the high-level requirements. Meanwhile, with the decision to publish a first draft of the API by the end of September, the group now concentrates on the API document.
The group agreed that the focus of the API specification should be on the retrieval of data from a DDR, rather than on provisioning, administration, security, access control, thread safety and so on. It was agreed that features such as provisioning are likely to be implementation specific, and that this should not be a problem. Only the retrieval of data places a high demand for standardisation and interoperability. Consequently, the group spent the remaining time discussing only the retrieval methods of the API.
From experience (of commercial systems) it was agreed that the most likely use case would be session based, and that multiple simultaneous sessions can be expected. This shall be mentioned in the high-level requirements (i.e. the Requirements document), and some comments about updates to the repository while sessions are active. Much of this behaviour, however, will be implementation specific as it will be outside of the scope of the API.
Issues related to errant runtime behaviour can generally be addressed via exceptions, and possibly aided by return codes, which will be covered in the API document.
The API specification will also include a section covering how bindings from the IDL to target programming languages shall be performed. There will be at least one normative binding (WSDL) and possibly a second (Java). For the main target languages there will be a set of guiding principles from which robust mappings can be obtained. It is hoped that the same principles could apply to programming languages that are not part of the main target languages.
The API specification will also contain all the IDL in a single section/appendix, with snippets from this section being used as illustration as appropriate elsewhere in the document.
Finally, unlike the current documents on the publication path, the API specification will be edited as a traditional W3C document, instead of a set of wiki pages. Versions of the document will be available in public on a regular basis, with commentary on the wiki.
The group recently considered the issue of sub-properties, using “image type” as a use case. In this example, one may discover that a device/browser supports GIF, but at a more detailed level one might discover that this actually means GIF-87 support but not GIF-89a. The problem is how to deal with such properties that may have sub-properties.
Fortunately, the ontology supports properties in a hierarchy, in addition to being able to uniquely identify properties by name. Therefore it should be possible to refine a query based on a previous response, assuming the response indicated that more information was available. For common queries, convenience functions may make these operations easy to perform.
It was also pointed out that one should not confuse the vocabulary with the ontology. Each item in the vocabulary will map to something in the ontology. The normative names should be one-to-one. For convenience methods and certain target languages, there will be additional names (e.g. CamelCaseFormat) that can be used (e.g. as method or variable names), but there will always be a way to support the normative names (e.g. via String parameters). The hierarchical relationship between properties will be determined by the ontology.
The group continued to explore the representation of different properties, including Booleans (which might have to support a “maybe” state). On the matter of representing support for specifications, the group considered the thorny issue of bugs. A browser than claims to support XHTML Basic 1.0, for example, is likely to fall short of perfect support. Strictly, therefore, few if any browsers will return “true” for this property. In practice, however, it is better to know that XHTML Basic 1.0 is supported, with a few caveats. Representing such caveats is a problem. Furthermore, the specifications are not necessarily complete. Support for tables does not imply that an arbitrary number of rows, columns or nested tables is possible. There are usually some implementation limits, chosen for practical reasons. How are such limits represented? Should we introduce a new named sub-property for each limit or caveat that is identified? Or should such additional information be captured as a set of values associated with a particular sub-property. In the former case, new sub-properties will require an update of the ontology and vocabulary. In the latter, only the set of permitted values for the set of values needs to be extended, and this might not require extending the ontology or vocabulary.
Recognising that there are different depths to which DDR queries may go, the group resolved that the DDR would provide both complex methods to obtain potentially complex data from the DDR, and convenient (simple) methods to obtain the data for cases where simple answers will suffice. For example, a query to obtain the usable width of the browser could involve a complex response to represent the usable widths for all known browsers on the device (in a case where the context key doesn’t reveal which browser is in use). Similarly, there may be a simple version of the same query that merely returns the pixel value for the current browser, or a default value (when the browser is not known).
It is not expected that convenience functions would target specific device properties, but would instead be more generic (e.g. getFirstOrDefaultValue(“propName”)). Naturally, individual implementations are free to provide additional convenience methods (e.g. getUsableWidthInPixels()).
The group further resolved that there should be a means of determining if a simple result can be further examined to reveal additional properties. This would be metadata accompanying a response from a query method.
The DDWG is working on the classification of devices as part of its work item on “structures”. The idea is to represent class membership as a machine computable expression using values from the device description vocabulary as input. Furthermore, local vocabularies may provide properties representing the result of external class membership decisions. For example, a machine computable expression may define the class of PDAs as mobile devices whose screen dimensions meets certain criteria and which has either a soft (stylus) or physical keyboard. Alternatively, the same device classification may involve assessment by humans, with the results of such assessments being captured in a Boolean value in a local vocabulary.
In the case of the machine computable expression, it would be possible for a designer to capture the class concept in an expression, and then at a later stage a Web site developer could use that expression as part of an adaptation process. It is important therefore that the expression language is independent of the Web solution language.
As a concrete suggestion, it was proposed that JSON (or possibly XPath) should be considered as a possible language for expressing class membership. More work will be done on this task and presented at a later meeting.
The last item on the agenda was to decide how to improve the group’s publishing process. Three publications are now agreed for the next two months, and this is broadly welcomed. The wiki, however, is less than appealing. One possible advance is to transition to a better wiki platform, which will improve the quality of the document presentation. Some experiments in this area will be done over the next few months.
The meeting concluded by thanking Vodafone for their hospitality.