Reuse issue in DISelect

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Reuse issue in DISelect

JOSE MANUEL CANTERA FONSECA

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

Reply | Threaded
Open this post in threaded view
|

RE: Reuse issue in DISelect

Rotan Hanrahan

You can place your conditional calculations in a custom XPath function and merely return Booleans to the DISelect page. If your calculations need to change, just update the XPath function implementation, and all your pages will now be using the new calculations.

Similarly, things like group membership can be dealt with externally.

The point, however, from a standardisation position is that external custom methods will reduce the portability of both the pages and the skills of the developer. So, if/when new properties or concepts (e.g. grouping) are proposed within a standardisation process, this should include the definition of common methods/functions and their binding in expressions such as those used in DISelect.

But of course you already know that. I'm just noting it here for the benefit of others who read this list. The DDWG will hopefully be working on a more comprehensive set of properties/methods and I expect these will be considered by DIWG, and we will see these advances coupled to DISelect in some way.

---Rotan.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of José Manuel Cantera Fonseca
Sent: 19 October 2006 10:27
To: [hidden email]
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


Reply | Threaded
Open this post in threaded view
|

RE: Reuse issue in DISelect

Rhys Lewis
In reply to this post by JOSE MANUEL CANTERA FONSECA

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: [hidden email] [mailto:[hidden email]] On Behalf Of José Manuel Cantera Fonseca
Sent: 19 October 2006 10:27
To: [hidden email]
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