RE: Reuse issue in DISelect

Hello Jose,

First let me say that you are absolutely correct, and that it is important to be able to reuse DISelect in very flexible ways. I'll be covering this in the next revision of the DISelect Primer, which is in progress right now. I'm currently working on some examples.

Rotan has already pointed out one mechanism for reuse in a separate answer. 

It is possible to use mechanisms based on embedding, as you point out. However, since W3C already has specifications that deal with this (XHTML V2, XInclude etc.), rather than invent a new mechanism, DISelect relies on these other mechanisms. I'll illustrate some in the primer. The idea is to write the DISelect in a separate document and simply to embed it where needed.

Another mechanism, that can reduce the need to rewrite expressions multiple times, relates to the ability to store the value of a DISelect expression in a variable. If the same test needs to be used multiple times within one document, the value of the appropriate expression can be computed once and saved in a DISelect variable. Subsequently, that variable can be used in tests in place of the expression, thus making the tests simpler. I'll illustrate that too in the primer.

On the question of device groups, this is a well known and well understood mechanism for dealing with diversity that is used by many operators and commercial implementations. Unfortunately, as yet there is insufficient basis in the current standards for us to formalise a mechanism for doing this in a standard way. It might be that the Device Descriptions working group might specify a standard property for this kind of device group. If that is the case, we could, in future, add an appropriate XPath function to the minimum set for DISelect to cover this.

In the meantime, and to take account of situations like this, where properties are useful but not yet standardised, we included in DISelect the ability to support extension XPath functions as long as they are outside the reserved DISelect namespace. Commercial implementations provide extensive access to additional properties using this kind of facility. Typically, this does include the ability to determine the group to which a device belongs. In at least one implementation, it is possible to add arbitrary new properties to be associated with individual devices or sets of devices.

Best wishes

Rhys Lewis

-----Original Message-----
From: www-di-request@w3.org [mailto:www-di-request@w3.org] On Behalf Of José Manuel Cantera Fonseca
Sent: 19 October 2006 10:27
To: www-di@w3.org
Subject: Reuse issue in DISelect


Dear all,

Another thread for another question. I'm envisaging the following issue
with DISelect and has to do with the reuse of conditions.

Imagine I'm a developer and bacause of the requirements of my
application I have to put the same selection conditions in several
authoring units. During the lifetime of the project I realize that those
conditions, that are spread over all the authoring units, are not
accurate. So, to fix it, I will have to edit all the authoring units and
change in all places my conditions.

Does DISelect have condition-reuse mechanisms that allow a developer to
avoid this issue?

With respect to those conditions that only has to do with the delivery
context subset composed by device properties (those found in the DDR),
Wouldn't it better that the developer could define (externally) groups
of devices, by means of logical conditions of belonging, and reference
those groups logically in the select expressions within the authoring units?

If due to some reason the conditions change I will only have to change
them in one place, outside the authoring units, that probably will be
developed by designers with no deed knowledge of device specific
technologies.

Thanks and best regards

Received on Thursday, 19 October 2006 11:23:54 UTC