URC Technical Primer 1.0 (DRAFT)

Note: This document is outdated and will not be further maintained.

Draft Technical Report 2012-10-22

This version: http://openurc.org/TR/urc-tech-primer1.0-20121022/
Latest version: http://openurc.org/TR/urc-tech-primer1.0/
Previous draft version: http://myurc.org/TR/urc-tech-primer1.0-20081124/ (changes marked)
Latest approved version: (none)
Editor: Gottfried Zimmermann

Copyright 2012, openURC Alliance


This document is intended as a read-me-first document for people interested in the URC technology and related standards, tools and resources that are available. First-time readers are advised to look at the referenced documents in the order as introduced in the prose text of this document.

Status of this Document

This is a public Draft Technical Report, developed by the editor, hereby made available for review by URCC members and the public.

Comments on this document should be sent to the editor.

Publication as a Draft Technical Report does not imply endorsement by the URCC membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Open Issues / To Dos [to be removed before release]

  1. Add more figures for illustration
  2. Add a section on structured content - dimensional vs. hierarchical data in variables
  3. Add section on what URC adds to UPnP (and other platforms). May be a whitepaper on its own.
  4. Mention the ability to share UCH modules via the resource server.

Change Log [to be removed before final release]

NOTE: The change log is in reverse chronological order.

2008-11-24 Gottfried Zimmermann:

2008-08-14 Gottfried Zimmermann:

Table of Contents:

1. Introduction

A good starting point for looking into the Universal Remote Console (URC) technology, its benefits and vision, is the [URC Whitepaper]. This includes some depicted scenario descriptions that are enabled through the URC framework.

The technical aspects of the URC technology are specified by a growing set of standards and guidelines. While the fundamental components and XML languages are specified by ISO/IEC standards, essential implementation guidelines and other support documents are provided as Technical Reports by the openURC Alliance.

2. The Basics

The goal of the Universal Remote Console technology is that every device or service can be accessed and controlled by any control device and user interface that fits the user's needs and preferences, using suitable input and output modalities and interaction mechanisms. In the following, we refer to the devices and services that are to be controlled as "targets", and to the control devices and their user interfaces as "universal remote consoles" (URCs).

NOTE: The term "Universal Remote Console (URC)" is used in two different ways: First, it is used for the control device and its user interface. Second, it denotes the overall technology and framework, as defined by the standards. In the following, we use the first meaning only, unless we explicitly invoke the broader meaning by saying "URC technology" or "URC framework".

In order to achieve this goal of a URC controlling a target without any prior knowledge of each other, some "common understandings" need to be in place that are commonly known by the URC and target. ISO/IEC 24752-1:2008 (read: "ISO/IEC standard number 24752, part 1, published 2008") defines the components of the URC framework and specifies these "common understandings" between them as conformance requirements for URCs and targets. These requirements for a "conforming URC" or a "conforming target" are stated in terms of high-level interaction with each other. A key part of this interaction is the sharing of control and access information through the following XML documents (as described in parts 2-5 of ISO/IEC 24752): User interface socket description, presentation template, target description, resource description. We will come back to these documents later.

Note that the URC framework, as defined by ISO/IEC 24752, does not pick a specific networking protocol between a URC and target. Part 1 only defines requirements for such a networking platform (called "TUN" for Target-URC-Network). The idea is that the URC related interaction could be implemented on top of existing networking platforms that support device discovery, control and eventing. However, in an existing network environment, targets and URCs have to commit to using a particular TUN implementation, in order to be interoperable with each other.

Please refer to [ISO/IEC 24752-1:2008] for details on the URC framework in general.

NOTE: You can easily remember the number of this standard as the "anytime standard", that is "24 hours by 7 days by 52 weeks".

NOTE: Unfortunately, we are not allowed to distribute the 5 parts of ISO/IEC 24752. You have to buy them from the ISO Store (list of web pages for purchase of ISO/IEC 24752).

2.1. User Interface Socket

An important requirement for a target is that it must expose its content and functions through one or multiple "user interface sockets" (or short "sockets"). A user interface socket is an abstract model of the user interface, hosting all its "ingredients" at runtime. In the URC framework, a socket consists of one or more of the following elements:

Within a socket, all variables, commands and notifications have unique names. At runtime, the socket is the single place for the URC to access a target's current state, and to change that state through modification of variables, calls on commands, and acknowledgment of notifications. The URC accesses the socket elements and represents them to the user in a way that is specific to the URC. It is important to note that the socket itself does not contain any information about how to present its elements in a user interface. This is completely up to the URC. That's why we refer to the socket as an "abstract user interface", as opposed to a "concrete user interface" that assumes specific interaction mechanisms for input and output.

It should be worth noting that the URC framework does not mandate any particular format of the socket and the data values it holds. The type of a variable, given as XSD type, is specifying its set of possible values (canonical value space), but not necessarily how these values are coded (lexical value space). The mechanism of how a URC accesses a target's socket and how the data values are coded is implementation specific and must be agreed upon between a URC and target in ways that are outside the scope of ISO/IEC 24752.

NOTE: The "Universal Control Hub", a specific profiling of the URC framework, fills this gap by defining data formats and socket APIs for specific implementation platforms. See section Universal Control Hub below.

2.2. User Interface Socket Description

A target must tell a URC how its sockets look like and what their elements are, through "user interface socket descriptions" (or short "socket descriptions"). The target manufacturer is responsible to prepare socket descriptions for every socket on their target.

A socket description basically contains a list of socket variables, commands and notifications (including their names). In addition to these three element types, "socket constants" (or short "constants") can be included to represent fixed or constant information that is known before runtime.

A socket description must follow the syntax and semantics of the "socket description language", as specified by ISO/IEC 24752-2:2008. It is a good practice to use the file extension ".uis" for socket description files. The MIME type for socket descriptions is "application/urc-uisocketdesc+xml".

As an example, here is a simple socket description for a digital thermometer [ISO/IEC 24752-1:2008]:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Note: This document should be served with a MIME type of “application/urc-uisocketdesc+xml”, if applicable -->

   xsi:schemaLocation="http://myurc.org/ns/uisocketdesc http://myurc.org/ns/uisocketdesc
      http://purl.org/dc/elements/1.1/ http://dublincore.org/schemas/xmls/qdc/2006/01/06/dc.xsd
      http://purl.org/dc/terms/ http://dublincore.org/schemas/xmls/qdc/2006/01/06/dcterms.xsd">

   <dc:creator>Trace R&amp;D Center</dc:creator>
   <dc:title xml:lang="en">User interface socket description for a digital thermometer</dc:title>

   <constant id="modelNumber" type="xsd:double">
   <variable id="temperature" type="xsd:double">
   <variable id="maximum" type="xsd:double">
   <variable id="minimum" type="xsd:double">
   <variable id="scale" type="scaleType"/>
   <command id="reset"/>
   <notify id="checkReset" category="alert">
         <explicitAck> false() </explicitAck>
            (uis:hasDefinedValue('confirmReset') and uis:value('confirmReset') eq 'done')
            or (uis:hasDefinedValue('cancelReset') and uis:value('cancelReset') eq 'done')
   <command id="confirmReset" type="uis:basicCommand">
         <relevant>uis:hasDefinedValue('checkReset') and uis:value('checkReset') eq 'active'</relevant>
         <write>uis:hasDefinedValue('checkReset') and uis:value('checkReset') eq 'active'</write>
   <command id="cancelReset" type="uis:basicCommand">
         <relevant>uis:hasDefinedValue('checkReset') and uis:value('checkReset') eq 'active'</relevant>
         <write>uis:hasDefinedValue('checkReset') and uis:value('checkReset') eq 'active'</write>

      <xsd:simpleType name="scaleType" id="idScaleType">
         <xsd:restriction base="xsd:string">
            <xsd:enumeration value="F"/>
            <xsd:enumeration value="C"/>


As you can see in the code, this sample socket descriptions specifies the following elements:

Note that the socket description does not contain any strings or other information that could be used as labels for the user interface. Except for some comments and <dc:description> elements, a socket description does not contain human-readable information. Instead, a URC should get labels, help texts and other "atomic resources" from external "resource sheets" (see section Labels and Other Resources below).

For further details on socket descriptions, please refer to [ISO/IEC 24752-2:2008].

2.3. Pluggable User Interfaces

Having a socket as abstract user interface, the idea is now to plug into it any concrete user interface that matches the elements in the socket. The concrete user interface would connect to one or multiple sockets in two directions: first, getting the values that reflect the current state of the target, and second, requesting changes in the target's state through variable changes and function calls. We call such a concrete user interface that connects to sockets, a "pluggable user interface" (PUI). The process of connecting a PUI's components to socket element is called "binding" or "grounding".

The URC framework imposes no constraints on PUIs in general:

In ISO/IEC 24752-1:2008, PUIs are called "User Interface Implementation Descriptions" (or short "UIIDs"). Contrary to socket descriptions, the provision of UIIDs is optional for target manufacturers.

ISO/IEC 24752-3:2008 specifies a special type of UIID, the Presentation Template (PreT), and an XML-based syntax for it. A PreT is a target-specific PUI that can bind to any number of sockets. It requires a runtime environment on the URC that can parse and interpret the PreT document, and bind it to the appropriate sockets. It is a good practice to use the file extension ".pret" for PreT files. The MIME type for PreTs is "application/urc-pret+xml". See [ISO/IEC 24752-3:2008] for details on Presentation Templates.

2.4. User Interface Resources

We have previously seen that the socket and its description do not include any labels or other static components of concrete user interfaces (let's call them "atomic resources"). This is on purpose since we want to be able to easily adapt user interfaces to locales and other user preferences. Therefore we store atomic resources in external files, called "Resource Sheets". (Actually, in some cases the resource sheet may just have a file pointer to an externally stored atomic resource). So, there can be multiple Resource Sheets for one target, each containing a different set of atomic resources for the target. For example, there may be a Resource Sheet for English labels, one for German labels, and one with graphical icons as labels.

A Resource Sheet can contain a variety of atomic resources, in different modalities (text, image, video, or any other digital medium that can be stored as a file with a known MIME type). There are five pre-defined "roles" (i.e. types) for atomic resources [ISO/IEC 24752-5:2008]:

The set of roles is extensible, i.e. you may define your own roles. However, before you do so, think about the consequences of introducing new roles in a resource sheet that a URC does not know - they will be useless. Unless you have your own closed system, you should make definitions of new roles available to the URC community. The URC Consortium is the authority for growing the URC ecosystem, and is welcoming proposals for new roles if they are useful for a broader community. In particular, we think that there will be a need for new roles in the area of semantic models and descriptions for control of devices and services ("semantic tagging" of socket elements).

A resource sheet must follow the syntax and semantics of the "resource sheet language", as specified by ISO/IEC 24752-5:2008. This language is based on W3C's Resource Description Framework (RDF) language. It is a good practice to use the file extension ".rsheet" for resource sheet files. The MIME type for resource sheets is "application/urc-ressheet+xml".

Here is an extract of a resource sheet for the digital thermometer [ISO/IEC 24752-5:2008]:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Note: This document should be served with a MIME type of “application/urc-ressheet+xml”, if applicable -->


   <dc:publisher>MyCorp, Inc.</dc:publisher>
   <dc:title xml:lang="en">Resource sheet for a digital thermometer</dc:title>
   <aResDescForDomain rdf:resource="http://example.com/thermometer/socket"/>
   <groupingForDomain rdf:resource="http://example.com/thermometer/socket"/>

   <!-- Description of the contained atomic resources -->

   <resItems rdf:parseType=”Collection”>
      <AResDesc rdf:about="http://example.com/thermometer/rsheet.rdf#temperature_label">
         <content rdf:parseType="Literal" xml:lang="en">Temperature</content>
         <useFor rdf:parseType="Collection">
               <eltRef rdf:resource="http://example.com/thermometer/socket#temperature"/>
               <role rdf:resource="http://myurc.org/ns/res#label"/>
      <AResDesc rdf:about="http://example.com/thermometer/rsheet.rdf#temperature_help_hint">
         <content rdf:parseType="Literal" xml:lang="en">Current temperature</content>
         <useFor rdf:parseType="Collection">
               <eltRef rdf:resource="http://example.com/thermometer/socket#temperature"/>
               <role rdf:resource="http://myurc.org/ns/res#help-purpose"/>

   <!-- More resource descriptions -->


Without going into details, you can see that a resource sheet has atomic resource descriptions (<AResDesc> elements). For each atomic resource description, there is one content (<content> element), and one or more use contexts (<Context> element). The use context describes (among other things) what socket element the atomic resource applies to (e.g. "temperature", and what role it assumes (e.g. "label").

A resource sheet and its atomic resource descriptions each have an identifier, given via the 'rdf:about' attribute. This identifier must be globally unique, that means that there is no other resource in the world with the same identifier. We recommend that you make a resource sheet available for retrieval by using a resolvable URI as its identifier. Following this practice, an atomic resource description with the identifier "http://example.com/thermometer/rsheet.rdf#temperature_label" can be obtained by retrieving the resource sheet from "http://example.com/thermometer/rsheet.rdf" and then looking inside for the <AResDesc> element with the appropriate 'rdf:about' attribute.

It should be noted that the application of atomic resources are not restricted to socket elements. In fact, it is recommended that you use atomic resource descriptions for your pluggable user interfaces as well. Atomic resources for a PUI have precedence to atomic resources for a socket description. In practice this means that if there is a label defined for the socket element "power", and also a label for the power button (as part of the PUI binding to the socket), the label for the power button should be used.

There is another (non-atomic) type of resource that a resource sheet can contain: grouping resources. Grouping resources define a presentation structure for socket elements. They can be used by (generic) pluggable user interfaces to build a structured user interface based on a socket description, atomic resources and grouping resources.

For details on resource sheets and atomic and other resource descriptions, see [ISO/IEC 24752-5:2008].

2.5. Target Description

At some point, there needs to be a portal for a target to advertise its socket descriptions and resource sheets. The "Target Description" document fulfills this role, as defined in ISO/IEC 24752-4:2008. A target manufacturer must provide exactly one target description for its target device or service. It is implementation-specific how a target makes its target description available to the URCs in a network. (This gap is filled by the UCH profile, see below.)

A target description must follow the syntax and semantics of the "target description language", as specified by ISO/IEC 24752-4:2008. It is a good practice to use the file extension ".td" for target description files. The MIME type for resource sheets is "application/urc-targetdesc+xml".

Basically, a target description provides pointers to a target's socket descriptions, and accompanying resource sheets. It may also contain pointers to external sources of resources, such as resource services. However, pointers to resource sheets and other resources are merely recommendations provided by the target manufacturer. AURC is free to look for supplemental resources at any other place it might know of, including resources that are built into the URC.

Here is a simple target description for the digital thermometer [ISO/IEC 24752-4:2008]:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Note: This document should be served with a MIME type of“application/urc-targetdesc+xml”, if applicable -->


   <dc:creator>Trace R&amp;D Center</dc:creator>
   <dc:title xml:lang="en">Target description for a digitalthermometer</dc:title>

   <locator type="audio" id="audio-locator"/>
   <locator type="visual" id="visual-locator"/>
   <locator type="other" id="irPing">
         <!-- The content of <extension> is not specified by this standard-->
         <ext:IRPing type="ext:basicIR"/>

   <socket id="socket" name="http://example.com/thermometer/socket">

   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:res="http://myurc.org/ns/res#">
      <!--Description of the root resource directory-->
         <res:dirItems rdf:parseType="Collection">
            <!-- Reference to resource sheet with English text labels for socket.-->
            <!-- Description of a UIID that is a presentation template for the digital thermometer. -->
            <res:UiidDesc rdf:about="http://example.com/thermometer/pret.xml">
               <res:forSocket rdf:resource="http://example.com/thermometer/socket"/>
               <dc:publisher>MyCorp, Inc.</dc:publisher>
            <!-- Description of a resource service that provides text labels for the thermometer's socket. -->
            <res:ResSvcDesc rdf:about="http://myurc.org/resservice.wsdl">
               <res:aResDescForDomain rdf:resource="http://example.com/thermometer/socket"/>
               <res:role rdf:resource="http://myurc.org/ns/res#label"/>
            <!-- Reference to another resource directory with references to resource sheets that contains labels, help texts,
               access keys, and keywords for the socket in different languages. Also it contains a grouping for the socket. -->
               <res:aResDescForDomain rdf:resource="http://example.com/thermometer/socket"/>
               <res:groupingForDomain rdf:resource="http://example.com/thermometer/socket"/>

From this example, let's pick a few parts and take a quick look at them. The 'about' attribute on <target> gives the target a globally unique identifer. It is good practice to make a web page available for the target under the target's identifier. The <locator> elements identify locators of the target, physical functions that can help a user find and identify a target (like beeping or flashing). This may be important for targets located in public environments (e.g. elevator). The <socket> element identifies a socket on the target, and points to the pertaining socket description. The <res:ResDir> element contains the "resource directory", a (possibly nested) list of pointers to resource sheets, UIIDs, and external resource services.

3. The Middleware Approach

Today, we are encountering a growing number of networked devices and services at home, at work, in schools and in public places. However, these devices and services are using different networking platforms and technologies, including UPnP/DLNA, CHAIN, OSGi, Web-based protocols such as UDDI, WSDL and SOAP, and many proprietary technologies. There seems to be no chance to get all manufacturers of these devices and services together to agree first to adopt the URC standards, and second to use a specific Target-URC Networking protocol for communication between URCs and targets. Instead, a different solution must be sought that can harvest the benefits of the URC standards, and works with existing devices and services available on the market.

3.1. Universal Control Hub

This is where the Universal Control Hub (UCH) comes in. It is a profiling of the URC standards that implements standard-conforming targets and URCs "in a box", and providing connection points to existing targets and controllers that are not URC-compatible. The UCH is a middleware that establishes a control connection between non-compliant controller and non-compliant target devices/services that would otherwise not understand each other. The UCH is designed to be extremely extensible and scalable with regard to diverse targets and controllers. By using the mechanisms as defined in ISO/IEC 24752, it provides an open platform for pluggable user interfaces that are based upon user interface sockets.

Components of the Universal Control Hub

Figure [UCH]: UCH architecture (description of image)

In the UCH architecture, any network-enabled device/software can be used as "controller". Also, the "Target" is a network-enabled device or service that can be remotely controlled via any networking platform. Note that this is different from a "conforming target", as defined by ISO/IEC 24752-1:2008. The "conforming UCH" and "conforming" targets are virtually folded into the UCH and its components.

The UCH discovers a target through a Target Discovery Manager (TDM), and controls it and receives events from it through a Target Adapter (TA). To a controller, the UCH makes itself discoverable through the UIList, an extended UPnP RemoteUI mechanism, as defined in [CEA-2014-A]. The UCH communicates with a controller for the purpose of target control through a User Interface Protocol Module (UIPM). By connecting to controllers and targets through these device and network-specific adapters, the UCH talks to them in their native language. Acting as a middleware, the UCH then translates the communication with targets and controllers into the "URC language", exposing the targets and their functions as sockets that the controllers can access. Thus the UCH bridges between non-conforming controllers and non-conforming targets, fulfilling the URC requirements on behalf of them.

NOTE: Since the whole URC system is now contained in a box, the TUN (Target-URC Network) is also contained in the box, degraded as function calls between the socket layer and a TDM/TA. The messages of this TUN are described as a set of two APIs.

There are many middleware products existing that bridge between controllers and targets in a similar way. What is unique for the UCH is that it uses a standard approach for the translation between targets and controllers, thus opening a way for third parties to make their pluggable user interfaces and accompanying resources available to the UCH after installation. The UCH constitutes an open platform for control interfaces that uses the mechanisms defined in the URC framework to allow for pluggable user interfaces and supplemental resources dynamically at runtime.

Moreover, the UCH architecture is designed to be extensible for new targets and controllers. Except for the core UCH (socket layer), its components (blue boxes: UIPMs, TDMs and TAs) are embedded into the UCH through well-defined APIs (red vertical boxes attached to the components). Any party can develop such components, and a UCH can load them at runtime. This mechanism is extremely powerful in conjunction with a resource server (see below). Then new targets and new controllers can be integrated into a local UCH system on the fly, by downloading the appropriate components from the resource server.

For more information on the Universal Control Hub, in particular if you are interested in the development of a UCH or any of its components, please refer to [UCH].

NOTE: An open-source reference implementation of the UCH has been developed by the Trace Center for Java and C/C++ platforms. For more information and download link, see http://myurc.org/tools/UCH.

3.2. URC-HTTP Protocol

In the UCH architecture, a UIPM is responsible for presenting one or multiple sockets to the user through a user interface that is rendered on a controller. In some cases, controllers and their software themselves might have knowledge about the URC technology, in particular about sockets and their resources. (These controllers are "conformant URCs", as defined by ISO/IEC 24752-1:2008.) They might want to get direct access to a target's socket and pertaining atomic resources, in order to build a suitable user interface based on the socket elements and their values.

The URC-HTTP protocol, as defined by [URC-HTTP], facilitates direct access for a controller to the sockets running in a UCH. This protocol defines HTTP-based messaging for a controller accessing the sockets on a UCH and its functions. An optional TCP/IP-based update channel is also defined. Please refer to [URC-HTTP] for details.

NOTE: The UCH open-source reference implementation by the Trace Center includes a UIPM for URC-HTTP. For more information and download link, see http://myurc.org/tools/UCH.

NOTE: Aside from being used as a user interface protocol in the UCH context, any "conforming target" (in the meaning of ISO/IEC 24752-1:2008) may employ the URC-HTTP protocol as a TUN (Target-URC Network). Any URC with URC-HTTP support would then be able to control it. This is a special case of the UCH architecture, in which the UCH and the target are merged into one unit, and only one UIPM is implemented (for the URC-HTTP protocol). This may be of particular interest to target manufacturers that want to make their products compliant to ISO/IEC 24752-1:2008 by incorporating an existing UCH implementation into their targets.

The URC-HTTP protocol is designed to be usable by clients running in Web browsers, such as scripts and plugins. For example, with the Webclient JavaScript Library, controller interfaces for specific targets can be easily written in DHTML (see demo video).

4. Resource Server

So far, the URC technology has been introduced as a framework that enables pluggable user interfaces and supplemental UI resources in a local network. The real power of the URC technology comes about when pluggable user interfaces, resources and UCH components are shared among users through a market place. We call this market place a "resource server".

The ISO/IEC 24752 standards mention the concept of a resource server tangentially, but do not provide requirements or recommendations for its implementation. Since a resource server is an important pre-requisite for a growing URC ecosystem, the URC Consortium has defined an open interface for resource servers that may be used by UCH and controller implementations. This interface is based on HTTP and HTTPS, and is specified in [RES-SERV-HTTP].

A prototypical resource server implementation is currently being developed and tested by the Trace Center (see http://myurc.org/tools/ResServer). It is expected that, based on the Trace resource server implementation, there will soon be a public resource server available for the URC community. Although not necessarily restricted to one global implementation, sharing of URC related resources will be simpler if there is only one resource server as opposed to multiple servers, possibly implementing different interfaces and protocols.

Sharing of resources implies attaching proper metadata on the resources so that other users can find them. There is a need for a global resource vocabulary in the URC community, similar to other vocabularies that have been established in the digital world (e.g. Dublin Core Metadata vocabulary). The "resource property vocabulary" [RES-PROP-VOCAB] specifies a core vocabulary for URC resources, based on RDF. In this vocabulary, a resource is assigned a flat set of properties, with each property named by a URI, and having a specified value domain. Implementers of URC technology should use properties from this core vocabulary whenever applicable. They may extend this vocabulary by additional properties and property values in cases where the core vocabulary is not deemed to be sufficient. If their extensions are potentially useful for the general URC community, they should notify the URC Consortium about them, and the Consortium will decide upon inclusion in a future version of the core vocabulary.

NOTE: Use of the "resource property vocabulary" is not restricted to resource server applications. In fact, a UCH should use these properties for internal communication between its components, see [UCH].

5. Guidance for Developers

There is a growing community of developers of URC technologies. The impact of implementations will be maximized by sharing common resources and following common guidelines. This is one of the objectives of the URC Consortium. Everybody is welcome to join this community and build a URC ecosystem that will facilitate simple, flexible, and accessible user interfaces for tomorrow - at home, at work, for education and in public places.

The following sections provide guidance for the development of specific parts of the URC ecosystem.

5.1. Overview of Tools and Projects

The tools page of the URC Consortium provides an overview of existing URC related tools and projects. You may find useful information and samples among them, including re-usable code. If you want to have your own project added to this list, please let me know.

5.2. Development of Socket Descriptions

For the development of sockets and socket descriptions, purchasing [ISO/IEC 24752-2:2008] is indispensable. Also, [ISO/IEC 24752-1:2008] is recommended.

Fortunately, some accompanying tools are available online for free:

There is currently no dedicated editor for socket descriptions.

The following projects in the URC community provide samples of socket descriptions:

You can simulate a virtual target (with a given target description and socket description) via the Generic Target Adapter of UCHj. Use the included Webclient in auto-generation mode to test your socket description.

5.3. Development of Target Descriptions

You should purchase [ISO/IEC 24752-4:2008] if you want to develop target descriptions. Also, [ISO/IEC 24752-1:2008] is recommended.

The following accompanying tools are free:

There is currently no dedicated editor for target descriptions.

The following projects in the URC community provide samples of socket descriptions:

You can simulate a virtual target (with a given target description, socket descriptions and resource sheets) via the Generic Target Adapter of UCHj. Use the included Webclient in auto-generation mode to test your target description.

5.4. Development of Presentation Templates

You should purchase [ISO/IEC 24752-3:2008] if you want to develop target descriptions. Also, [ISO/IEC 24752-1:2008] is recommended.

The following accompanying tools are free:

There is currently no dedicated editor for presentation templates.

NOTE: There are currently no URCs that support the presentation template language. You should consider pros and cons before launching a bigger effort on the development of presentation templates. Alternatives include existing user interface languages with support on various controller devices, such as DHTML, Flash, etc.

5.5. Development of Resource Sheets

You should purchase [ISO/IEC 24752-5:2008] if you want to develop resource sheets. Also, [ISO/IEC 24752-1:2008] is recommended.

The following accompanying tools are free:

In the future, the URC community may provide an XML Schema and a Schematron file for resource sheets.

There is currently no dedicated editor for resource sheets.

The following projects in the URC community provide samples of resource sheets:

You can simulate a virtual target (with a given target description, socket descriptions and resource sheets) via the Generic Target Adapter of UCHj. Use the included Webclient in auto-generation mode to test your resource sheets.

5.6. Development of UCHs, UIPMs, TDMs and TAs

If you want to develop a UCH, or a component thereof, you should follow [UCH].

Also, you may want to look at Trace's reference implementations of UCH (see UCHj for Java, UCHe for C/C++), including:

You can test your TDM and TA in UCHj or UCHe, using the included Webclient in auto-generation mode.

5.7. Development of URC-HTTP Clients

If you want to develop DHTML applications, using the URC-HTTP protocol to connect to the UCH, you should take a look at the Webclient JavaScript Library, in particular:

The UCHj and UCHe projects each include an installation of the Satellite Box Applet that can be controlled through an HTML template (as described in the above tutorial).

NOTE: Libraries that facilitate the development of URC-HTTP clients for other platforms (e.g. Flash, MSML, Silverlight) will be needed in the near future.

Other projects using the URC-HTTP protocol (but not the Webclient JavaScript Library) are:

6. References

For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

CEA-2014-A: Web-based Protocol and Framework for Remote User Interface on UPnP™ Networks and the Internet (Web4CE).  P. Shrubsole, W. Dees, 2007.
[ISO/IEC 24752-1:2008]
ISO/IEC 24752-1:2008. Universal Remote Console - Part 1: Framework. Available from ISO Store for purchase: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=42309
[ISO/IEC 24752-2:2008]
ISO/IEC 24752-2:2008. Universal Remote Console - Part 2: User Interface Socket Description. Available from ISO Store for purchase: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=42310
[ISO/IEC 24752-3:2008]
ISO/IEC 24752-3:2008. Universal Remote Console - Part 3: Presentation Template. Available from ISO Store for purchase: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=42311
[ISO/IEC 24752-4:2008]
ISO/IEC 24752-4:2008. Universal Remote Console - Part 4: Target Description. Available from ISO Store for purchase: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=42312
[ISO/IEC 24752-5:2008]
ISO/IEC 24752-5:2008. Universal Remote Console - Part 5: Resource Description. Available from ISO Store for purchase: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=42313
URC Consortium: Resource Property Vocabulary. Latest specification available at: http://myurc.org/TR/res-prop-vocab/.
URC Consortium: Resource Server HTTP Interface. Latest specification available at: http://myurc.org/TR/res-serv-http/
URC Consortium: Universal Control Hub. Latest specification: http://myurc.org/TR/uch/
URC Consortium: URC-HTTP Protocol. Latest specification available at: http://myurc.org/TR/urc-http-protocol/
[URC Whitepaper]
Interface Sockets, Remote Consoles, and Natural Language Agents. A V2 URC Standards Whitepaper. Latest version: http://myurc.org/whitepaper.php
[XML Schema Definition]
XML Schema Part 2: Datatypes Second Edition. W3C Recommendation 28 October 2004. http://www.w3.org/TR/xmlschema-2/