2004-03-12
This is the ReadMe
file accompanying the set of draft standards comprising the URC standard, as of
2004-03-09, as submitted to INCITS V2 members to vote on release for public
comments. The purpose of this note is to
provide an overview of the documents.
WARNING
These documents are draft working papers of INCITS/V2, the Information Technology Access Interfaces Technical Committee of the InterNational Committee for Information Technology Standards. They do not represent an official position, recommendation, specification, or standard of INCITS/V2, INCITS, ANSI, ISO or IEC. They are subject to change or withdrawal, at any time, without notice. Any implementation, rendition, or model based on the content of these documents is done at the risk of the implementer.
ALL RIGHTS RESERVED. These documents are provided for information and comment only. Comments on these documents should be sent to info-v2@nist.gov. Reproduction or redistribution of these documents for information or comment is authorized, only if the entire document set, including this notice, is provided. No other use of these documents is authorized without written permission from INCITS/V2.
© 1998, 1999, 2000, 2001, 2002, 2003, 2004 INCITS
This set consists of five
draft standards, and it is recommended to read them in this order:
·
V2-URC.doc:
"Protocol
to Facilitate Operation of Information and Electronic Products through Remote
and Alternative Interfaces and Intelligent Agents: Universal Remote
Console". Specifies the URC framework
and technical components of the standard.
This should be the first document read by those unfamiliar with the URC
standard and its scope. This document
provides requirements for Targets, URCs and the network that connects them.
·
V2-TPS.doc:
"
Protocol to Facilitate Operation of Information and Electronic Products through
Remote and Alternative Interfaces and Intelligent Agents: Target
Properties Sheet". Describes the
Target Properties Sheet component of the Target.
·
V2-UIS.doc:
"
Protocol to Facilitate Operation of Information and Electronic Products through
Remote and Alternative Interfaces and Intelligent Agents: User Interface
Socket Description". Describes
the User Interface Socket Description component of the URC Portal.
·
V2-PT.doc:
"
Protocol to Facilitate Operation of Information and Electronic Products through
Remote and Alternative Interfaces and Intelligent Agents: Presentation
Templates". Specification of a
language for providing a Presentation Template.
A Presentation Template is a modality-independent scaffold for a UI that
provides the necessary structure and hints to build a browsable
user interface.
·
V2-RD.doc:
"
Protocol to Facilitate Operation of Information and Electronic Products through
Remote and Alternative Interfaces and Intelligent Agents: Resource
Descriptions". Specifies how to
specify resources and resource descriptions for UI components that are used in
building concrete user interfaces, including labels, help texts, access keys
and keywords.
Within the documents,
references to the other documents are currently denoted by [V2-UIS], etc. These references will be replaced with the
document numbers when these are issued by INCITS.
Note: The standard
drafts do not specify how to implement the URC framework on top of existing
networking platforms, such as Universal Plug and Plug, or Java/Jini.
V2 is seeking feedback
on specific aspects of the specifications, as described below.
Reference: Universal Remote
Console document, 7.2.4 Portal Resources, User Interface Socket Description Section 7 Structure of a Socket
Description, Presentation Templates, Section 10: Resources for Presentation
Templates.
In general, resources
are provided external to the context to which they apply, and not as
subelements of the XML element to which they pertain. V2 is seeking feedback from potential URC
implementers as to how this impacts the performance and resource demand of
small URC devices.
[V2 Internal reference: IssueN103, IssueN36]: Default labels, help texts, access keys and keywords that pertain to the elements in the UI socket or Presentation Template are to be defined separately as portal resources (see Resources document). V2 is seeking feedback from reviewers on whether the implementers of URCs would prefer having the default resources specified in-line (as part of the Socket Description or Presentation Template document). Previous discussions have led to the following pros and cons:
Pros (for in-lining): Potentially easier to implement and less resource-intensive on URC: (1) Merging UI socket description and default resources is resource-intensive. (2) URC would not have to deal with XPointer syntax when using default resources only.
Cons (against in-lining): (1) In-lining would not fit to the fetch mechanism that allows the URC to pick the appropriate resources. In-lining would therefore not provide a simple solution for i18n. (2) Changing a label within the UI Socket or Presentation Template document would make it necessary to assign a new identifier (or at least a new modification date) to the document. (3) Clean separation of structure and human-readable content, reflected in the documents.
Reference: Resource Descriptions document, Section 7.1
Relation to Dublin Core Metadata Element Set
INCITS V2 is seeking
feedback on the use of the Dublin Core Metadata Element Set.
References: Resource Descriptions document, Section
8.5 The <contentLocalAt> element, Resource
Descriptions document, Section 9.5 The <localAt>
element, Resource Descriptions document, Sections 10.8 and 12.4 The <localAt> element,
V2 is seeking feedback
from experts related to the separation of <contentGlobalAt>
and <contentLocalAt>, and the separation of
<globalAt> and <localAt> . These elements
have been defined separately so that URCs can quickly retrieve resources, resource
sheets, UIIDs and Resource Sheet Collections from the local network
environment. Should we merge these
elements and leave it up to the URC to find out whether the URI is local or
global by parsing the URI and its schema?
Reference: Universal
Remote Console document, section 10.1.2.1 Scope of Discovery (Network
Requirements)
In order to facilitate
access to non-local targets, Target-URC Networks are required to support sessions
between a URC and any Target that is accessible via the network, provided the
Target's address is known in advance by the URC, and there are no network
security restrictions preventing operation of the Target through the network. The current draft reads: "At a minimum, if a
Target address is known, and that address is accessible through the Target-URC
Network, and any network authorization requirements are satisfied, it SHALL be
possible to initiate a control session with the Target." V2
is seeking feedback as to whether this should be a requirement (denoted by 'SHALL')
or a recommendation (denoted by 'SHOULD').
If a recommendation,
then some Target-URC Networks may not allow users to access any Internet-based
Targets, even though the Network itself can access the Internet. If it is a
requirement, then should the definition of 'accessible via the network' be
explicitly limited to access routes that support the URC standard? Is it reasonable to make this a requirement
across all network types and gateways?