INCITS/V2 Technical Committee
Information Technology Access Interfaces
December 19, 2004
Reply to: Joe Roeder, V2
Secretary
Email: jroeder@nib.org
DOC: V2/04-0104
MINUTES of INCITS V2 PLENARY MEETING #17
Meeting Location: This meeting was hosted by the Trace Center, University of Wisconsin, Madison in Madison, WI.
Meeting Dates:
Mr. Bill LaPlant, Chair of INCITS-V2, welcomed the members and guests.
REF:
<http://www.incits.org/tc_home/v2htm/docs/v2/sd-01/v2sd01a.htm>
A quorum is present with 7 member organizations represented.
REF:
<http://www.incits.org/tc_home/v2htm/docs/v2/04-0079/v2040079.htm>
<http://www.itl.nist.gov/twiki/bin/view/ncitsv2/agendaitems>
Nno modifications were made to the agenda.
<http://www.incits.org/tc_home/v2htm/docs/minutes/0310v2p13/v2030100.htm>
<http://www.incits.org/tc_home/v2htm/docs/minutes/0403v2p15/v2040032.htm>
<http://www.incits.org/tc_home/v2htm/docs/minutes/0406v2p16/v2040056.htm>
Without objection, the referenced minutes were approved by unanimous consent.
REF:
<http://www.itl.nist.gov/twiki/bin/view/NCITSV2/ActionItems>
Due to time constraints, review of the action items was skipped. The Chair reminded the member delegates to update their action items on the Twiki collaboration site.
Due to time constraints, the administrative reports were skipped.
REF:
<http://comelec.afnor.fr/iso/jtc1/sc35jtc1/sc35>
<http://www.itl.nist.gov/twiki/bin/view/NCITSV2/InternationalTickler>
<http://cio.nist.gov/esd/emaildir/lists/v2sc35/msg00412.html>
V2 could not make a formal recommendation, because unexpectedly at the end of the meeting, a quorum no longer existed. However, the remaining 6 Principal Member delegates agreed to the following informal recommendation:
Informal recommendation: We recommend to add new NP criteria as proposed by the SC35 report, J1N7571. We feel that the proposed NP criteria will motivate new work item proposers to consider issues on user accommodation when planning for a new project. In particular, we support the addition of E.3 "Features for the Accommodation of Human Functioning" and E.4 "Features for the Accommodation of Context of Use" in an effort to ensure that the standard technologies are appropriately robust.
U.S. Delegation and Head of Delegation for SC35 "General Orientation Meeting".
The Chair appoints Gottfried Zimmermann as Head of Delegation for the General Orientation Meeting of SC35 in Stockholm, November 22-26, 2004. Zimmermann will send the list of delegates to INCITS.
FYI
<http://cio.nist.gov/esd/emaildir/lists/v2sc35/msg00408.html>
<http://www.jtc1.org/ListOfFiles.asp?DocNumber=7612&SubComm=ISO%2FIECJTC1&Private=True>
FYI
<http://cio.nist.gov/esd/emaildir/lists/v2sc35/msg00419.html>
<http://www.jtc1.org/ListOfFiles.asp?DocNumber=7611&SubComm=ISO%2FIECJTC1&Private=True>
REF:
<http://jtc1sc36.org/>
No report.
No report.
http://www.w3.org/wai/
No report.
REF:
http://www.upnp.org/
No report.
No report.
No report.
No report.
No report.
No report.
No report.
Zimmermann gave a demo of the Trace prototype.
REF:
http://www.itl.nist.gov/twiki/bin/view/NCITSV2/CommentsReceivedDuringPublicReview
ACTION ITEM (LaPlant) work with a reconstituted V2A on the construction of response letters to commenters.
MOTION (V2A) V2 accepts comment INCITS389GottfriedZimmermannComment1 and implements the proposed changes.
The motion passed by unanimous consent.
MOTION (V2a): V2 respond to comment INCITS389TVRamenComment1 with:
"We believe that getting Targets to expose a data model underlying their dialog, and expressing the model in XML gets us to the tipping point where the mix-and-match capabilities that result will grow the market for players from either side (Target or URC). We don't want to ask our implementors for more than what it takes to reach that point.
"We hear XForms advancing this strategy and will be delighted with any and all
uptake the XForms technology achieves. We have not chosen to take the XML requirement down to a second level below the model,
because it may retard adoption among some communities developing devices on the small end with regards to compute capability. But
URC and XForms implementations will be easy to make interoperable and the differences in the profiles of practice leave few
obstacles to a future convergence."
The motion passed by unanimous consent.
MOTION (V2A): V2 respond to comment INCITS389TVRamenComment2 with:
"We believe that getting Targets to expose a data
model underlying their dialog, and expressing the model in XML gets us to the tipping point where the mix-and-match capabilities
that result will grow the market for players from either side (Target or URC). We don't want to ask our implementors for more than
what it takes to reach that point.
"Due to its architecture and use of declarative languages, this standard does not constrain URC implementers in deploying the URC
functionality across a distributed environment, as requested in the comment. "Standardizing the unbundling of URC processing
cannot be done without imposing contstraints on the initially more critical unified implementation. Thus we do not believe that
this level of standardization is advantageous for the standard
as it seeks initial implementations."
The motion passed by unanimous consent.
MOTION (V2A): V2 respond to comment INCITS389TVRamenComment3 with:
"We are not trying to make every URC be universal
in addressing the needs of any user. Each URC is 'universal' in operating any Target implementing the Standards, but it is not
'universal' as regards user interface physics or style. Rather, it is 'uniform' with other URCs in the machine-to-machine
face that faces the Target.
"So to minimize the constraints we lay on people by our standard, we leave to the productizer the decisions as to which functions
should be componentized or conversely which sets of layers should be fused in a given implementation.
"As a result we are reluctant to impose specfic layerings or XML technology on the implementers beyond the essentials, as
suggested in the response to Comment 1. There is credible evidence that to do so could slow down adoption among implementers of
devices with small compute capabilities, at least in the near term (which is of great importance for us). So we have aligned our
technology demands with those of XForms in asking for a model, and asking that the model be in XML, but not taking the XForms
package in its entirety."
The motion passed by unanimous consent.
MOTION (V2A): V2 respond to comment INCITS389TVRamenComment4 with:
"We believe that getting Targets to expose a data
model underlying their dialog, and expressing the model in XML gets us to the tipping point where the mix-and-match capabilities
that result will grow the market for players from either side (Target or URC). We don't want to ask our implementors for more than
what it takes to reach that point.
"The XForms processing model may enable shared code across different implementations in the eventualconvergence of device and
service operation. On the other hand in the short term it is not clear that specifying the processing model beyond what we have
done is necessary for the nucleation of communities of interoperation on either end of the handshake specified by the URC
Framework. To get started we are concerned not to raise any unnecessary barriers to early adopters."
The motion passed by unanimous consent.
MOTION (V2A): V2 respond to comment INCITS389TVRamenComment5 with:
"We believe that getting Targets to expose a data
model underlying their dialog, and expressing the model in XML gets us to the tipping point where the
mix-and-match capabilities that result will grow the market for players from either side (Target or URC). We don't want to ask our
implementors for more than
what it takes to reach that point.
"For example, using Namespaces in XML to combine XForms and novel meta-controls would
require a namespace-aware XML processor. Even the XHTML2 design has brought XForms directly into their own namespace to avoid
imposing this requirement."
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees with comment INCITS389RichSchwerdtfegerComment1 and will make
appropriate changes.
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS389RichSchwerdtfegerComment2 with:
"V2 disagrees with
your comment because Jini covers only discovery. Our requirements on "networking platform" include the functionality of
controlling and event notifications. This is why Jini alone is not sufficient, and we need an RPC mechanism such as Java RMI."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS389RichSchwerdtfegerComment3 with:
"V2 disagrees with
your comment because in XForms (and others) hints and help are two different categories. In this standard hints are a subtype of
help, with the role help/purpose, provided as resources in resource sheets. See INCITS 393-2004, section 8.9.4."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS389RichSchwerdtfegerComment4 with:
"Yes, conflicts may occur between 1) access keys suggested in resources for a target and 2) access keys currently in use in the URC.
"Should
this happen, the URC is able to replace access keys. It may bind actions to an alternate key (as access key) if another key is
available. Access keys are resources and all resources are replaceable at the URC's discretion.
"On the other hand, there may not be any accesskey capability in the URC. It could be an all-audio URC using voice command. The
URC is required to give the user a functional presentation: some means of activating the command. The fact that a label resource
exists for the command ensures that some sort of menu or prompt can be constructed. The URC is not necessarily required to provide
direct access via a keypress to this activation."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS389RichSchwerdtfegerComment5 with:
"RDF is used to
describe resources, resource sheets and what we are now calling "resource directories". Please refer to INCITS 393-2004 which
contains an RDF schema for resource descriptions."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS389RichSchwerdtfegerComment6 with:
"This standard does
not specify how a target's state is stored. In other words, the target is free to store the values of its socket elements in any
form, including proprietary and binary formats. The socket description specifies the structure of the socket, i.e. its
variables, statics, notifications and commands, but not their values or how they are invoked. This is up to the TUN. This is a
significant difference between our standard and XForms."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS389RichSchwerdtfegerComment7 with:
"Yes, we have looked
at LMS when looking at user preferences schemas. INCITS389 will interoperate with any preferences schema."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS389RichSchwerdtfegerComment8 with:
"Hints are a
subcategory of help. Groupings are in the presentation template. Dependencies between objects can be specified in the socket.
These definitions are part of INCITS 391-2004, Presentation Template, and INCITS 390-2004, User Interface Socket Description."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS389RichSchwerdtfegerComment9 with:
"Session forwarding is
facilitated by the URC. There is no target-to-target communication for the purpose of session forwarding. When a target/portal
wants to forward to another target/portal, it sends a message to theURC telling the URC which target/portal it should go to.
The URC is then supposed to close the session with the existing target/portal and open a session with the referenced
target/portal."
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees with comment INCITS389JunePerrittComment1 and will make
appropriate changes.
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees with comment INCITS389JunePerrittComment2 and will make
appropriate changes.
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees with comment INCITS389JunePerrittComment3 and will make
appropriate changes.
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS389JunePerrittComment4 with:
"We are required to write
the glossary in this style, according to the ISO style guide."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS389JunePerrittComment5 with:
"The labels have the
following functions:
<target> and <portal>: Display a target's name and a portal name to the user.
<locator>: Display the name of a locator to the user so that they can invoke it.
<uisocket>: Display the title of the user interface (if not overridden by the UIID).
<static>, <variable>, <command> and <notify>: Labels for controls that are bound to the socket element (if not overridden by the
UIID).
Type in socket description: Types may be used for structuring a set of selections. The URC may want to display the name of a group
(i.e. a type) to the user.
Enumerated value in socket description: Enumerated values can be part of a selection set, and their names should be displayed to
the user.
<pret>: Display the title of the user interface.
<group>: Groups are used to structure the user interface. A URC may want to display a group name to the user, e.g. as a label of a
group box. In general, labels are provided externally in resource sheets to allow for
substitution in internationalization and individualization."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS389JunePerrittComment6 with:
"Yes, there may be timeouts
on the network layer where the user may not be given advance notice. With regard to this, the standard does make recommendations
in section 7.4.4 with regard to target and URC behavior."
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees with comment INCITS389RenatoLevyComment1 and will make appropriate changes.
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS389RenatoLevyComment2 with:
"The User Interface Socket is
a socket you plug an alternate user interface into. We find the term "user interface socket" to be useful in explaining the
function of the standard and the socket to people unfamiliar with the standard."
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees with comment INCITS389RenatoLevyComment3 and will make appropriate changes.
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees with comment INCITS389RenatoLevyComment4 and will make appropriate changes.
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees with comment INCITS389RenatoLevyComment5 and will make appropriate changes.
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees with comment INCITS389RenatoLevyComment6, noting that a notification has a "state" rather than a
"status", and will make appropriate changes.
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees with comment INCITS389RenatoLevyComment7 and will make appropriate changes.
The motion passed by unanimous consent.
MOTION (V2A) V2 respond to comment INCITS389RenatoLevyComment8 with:
"V2 agrees that security is a very key element.
However, we feel that it is better to separate security concerns from the dialog-representation concerns addressed in this
standard. Application areas for this standard come with very diverse security requirements. Technically, it is easy to separate
security concerns from the interface-abstraction techniques set out here. That is to say this aspect integrates easily with
security solutions withoutimposing a particularly high cost or constraining the choice of security solution. Also, the security
that would be appropriate for a particular target may vary widely depending on the context of use. The target manufacturer would
have no way of knowing this at the time of manufacture. Therefore it is better to have separate standards, even 'though many of
the targets implementing this technology should, and many will, implement security functions as well. However, it will be
very important for manufacturers to consider and make provisions for security. And we are very interested in developing
documentation and outreach materials on security as it relates to implementations of V2 specifications - and we welcome any
assistance in this effort."
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees to comment INCITS389RenatoLevyComment9 and will make appropriate changes.
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS389RenatoLevyComment10 with:
"The system already behaves
as you wish. The target is autonomous; it is the ultimate arbiter as to how it responds to URC communications. If the URC
discovers the Target it may address requests to the Target, but the Target may or may not respond."
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees to comment INCITS389RenatoLevyComment11 and will make appropriate changes.
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS389RenatoLevyComment12 with:
"We do not believe that this
added complexity is useful often enough among our use cases to merit complicating the simple asynchronous processing of URC
messages as discussed in response to your comments numbered 9 and 11. Most of the time we expect Targets to respond, if they can
at all, in time which is fast relative to userperception and action."
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees to comment INCITS389RenatoLevyComment13 and, in consultation with the commenter, will work out a
solution.
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees to comment INCITS389RenatoLevyComment14 and, in consultation with the commenter, will work out a
solution.
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees to comment INCITS389RenatoLevyComment15 and, in consultation with the commenter, will work on a
solution.
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS389RenatoLevyComment16 with:
"Yes, it is somewhat
redundant, but we wanted to have two seperate sets of instructions, one for URC manufacturers, one for Target manufacturers."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS390EdPriceComment1 with:
"Perhaps add to a tutorial to
the implementation guides or similar documents later. Since the standard is using XSD syntax for typing and constraining
value domains, it currently only allows for static minimum and maximum values. As you suggest, the calculate attribute could be
used as a help construct when determining a valid value from a possibly invalid value. Though there are no min() and max()
functions, the same effect can be achieved by the following valid XPath expressions:
min(x, y) can be calculated by: (x <= y)*x + (x > y)*y
max(x, y) can be calculated by: (x >= y)*x + (x < y)*y
In future versions of the standard we will consider adding support for dynamically constraining a variable's value space."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS390EdPriceComment2 with:
"It is not necessary to
'overload' the value() function to accommodate the return of different data types.
Types in XPath are 'soft', meaning that one type can be treated as any other-- XPath has rules that govern the implicit conversion
between logical types. For example, the following expressions are valid:
"5" + 7.5 + true() [returns 13.5]
concat( 123, "456", true()) [returns "123456true"]
not( "turkey" and 1) [returns False]
To implement XPath's soft types in a strongly typed language like C++, its necessary to write a special XPath object class to
represent XPath's number, string and Boolean types and handle the implicit type conversions that are required. Implementations for
the XPath functions and operations then take arguments of this new XPath object type, rather than arguments explicitly typed to
conventional string, Boolean, or 'number' (double) types."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS390JunePerrittComment1 with:
"XML is widely used for the
function that the Socket Description performs -- characterizing the dialog opportunities. The XML-specific processing, an XML
parser, is available in many languages and development libraries. The code implementing the standard on the URC side is
expected to be new code,
although members of INCITS V2 are seeding the process with implementation toolkits. On the Target side, the implementation is a
TUN interface to Target operation, a remote operation capability they have already decided they want in a TUN that they choose;
plus a bit of extranet technical-data publishing for which XML is rapidly becoming the dominant medium. It helps to look
carefully at the use of the Socket Description. While this is
an XML document, it informs the URC of the model implemented by the dialog carried over the Target-URCNetwork (TUN), but the
messages passing over the TUN are not required to encode the information in XML. The Socket Description in the URC framework
performs a function comparable to that of the WSDL document in a Web Service or the 'model' element in an XForms application.
The Target does not have to have a browser because it is not enabled (by this standard) to browse the universe of users. It speaks
when spoken to. The URC user can 'browse' to the extent of discovering Targets. But the task model directly supported by the
standard is that a task can be performed communicating with one Target within the capabilities of that Target. "The beef" in a URC
dialog is task performance operating the Target, not browsing the space of communicating Targets."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS390JunePerrittComment2 with:
"Section 9.1 introduces the
<command> element which is inside the <uiSocket> element. The <command> element specifies a command that the URC can make
available to the user. A list of commands can be
specified by including multiple <command> elements in a sequence."
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees to comment INCITS390PerrineRoucouxComment1 and will make appropriate changes.
The motion passed by unanimous consent.
MOTION (V2A) V2 accepts comment INCITS390GottfriedZimmermannComment1 and, in consultation with the commenter, will work out
a solution.
The motion passed by unanimous consent.
MOTION (V2A): V2 respond to comment INCITS391TVRamanComment1 with:
"We believe that getting Targets to expose a data
model underlying their dialog, and expressing the model in XML gets us to the tipping point where the mix-and-match capabilities
that result will grow the market for players from
either side (Target or URC). We don't want to ask our implementors for more than what it takes to reach that point.
"For example, using Namespaces in XML to combine XForms and novel meta-controls would require a namespace-aware XML processor.
Even the XHTML2 design has brought XForms directly into their own namespace to avoid imposing this requirement."
The motion passed by unanimous consent.
MOTION (V2A) V2 accepts comment INCITS391GottfriedZimmermannComment1 and, in consultation with the commenter, will work out
a solution.
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees to comment INCITS391PerrineRoucouxComment1 and will make appropriate changes.
The motion passed by unanimous consent.
MOTION (V2A) V2 respond to comment INCITS392AlGilmanComment1 with:
"V2 agrees to the thrust of the comment that
resources should be defined broader and responds as follows:
We don't feel that the outsourcing of geocoordinates is necessary. To address the problem you describe we suggest that the target
implement a simple mechanism that would construct the TPS on the fly by filling in installation-time information. Alternatively
the target could generate the TPS at installation
time, based on user input (this would, however, require that the TPS be stored on writeable memory). The proposed mechanisms are
not too complex for public targets which would typically use the element. However, in pondering on your comment we feel that
the current definition of resource, as given in INCITS 389, is too narrow, in particular for accommodating Semantic Web concepts:
"identifiable object of a user interface that is used as
an atomic entity in the construction of a concrete user interface". We will change INCITS 389 to reflect a wider definition of
resource.
The motion passed by unanimous consent.
MOTION (V2A) to reconsider and amend the previous motion.
The motion passed by unanimous consent.
MOTION (V2A) V2 respond to comment INCITS392AlGilmanComment1 with:
"V2 agrees to the thrust of comment
INCITS392AlGilmanComment1 that resources should be defined more broadly. However, we don't feel that the outsourcing of
geocoordinates is necessary. To address the problem you describe we suggest that the target implement a simple mechanism that
would construct the TPS on the fly
by filling in installation-time information. Alternatively the target could generate the TPS at installation time, based on user
input (this would, however, require that the TPS be stored on writeable memory). The proposed mechanisms are not too complex for
public targets which would typically use the <location>
element.
"However, in pondering on your comment we feel that the current definition of resource, as given in INCITS 389, is too narrow, in
particular for accommodating Semantic Web concepts: 'identifiable object of a user interface that is used as an atomic entity in
the construction of a concrete user interface'. We will
change INCITS 389 to reflect a wider definition of resource."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS392JunePerrittComment1 with:
"The namespace URI
http://www.incits.org/v2/2004/tps mentioned in section 2 is currently not resolvable. This is not a requirement for namespace URIs
(see section 2 in [1]). However, V2 intends to post appropriate information to the namespace URI upon approval of the standard.
[1] Namespaces in XML, World Wide Web Consortium 14-January-1999, http://www.w3.org/TR/REC-xml-names/."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS392JunePerrittComment2 with:
"Section 7.1 does not
formally introduce the attributes and subelements of <target>. The example shown in section 7.1 serves as an (informal)
illustration only. See sections 7.2 through 7.12 for the
definitions of required and optional attributes and elements."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS392JunePerrittComment3 with:
"Yes, we have made edits to
the document to clarify."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS392JunePerrittComment4 with:
"The URI
http://www.incits.org/v2/2004 as value of the <dcterms:conformsTo> element is not meant to be resolvable. It is used as a global
identifier, not to retrieve a document."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS392JunePerrittComment5 with:
"The <location> element
provides an anchor point for (language specific) location information, given in natural language. It is necessary that it bears an
id attribute so that language specific resources can refer to it. In
addition, the <location> element may contain geocoordinates. The structure of INCITS 392-2004 is that section 7.1 introduces the
<target> element in general, and subsequent subsections introduce the attributes and
subelements of <target>. <location> is a subelement of <target>. Your confusion is caused by the document structure that is
required by the ISO styleguide."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS392JunePerrittComment6 with:
"Yes, the coordinates are
for the Target. The <geocoordinates> element may contain any type of geographical information of the target, including GPS
coordinates. The type is indicated by the namespace and
elements used to specify the coordinates. INCITS 392-2004 does not prescribe any particular namespace or type of geographical
information."
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees to the comment INCITS392JunePerrittComment7 and, in consultation with the commenter, will work out a
solution.
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees to comment INCITS392JunePerrittComment8
and will make
appropriate changes.
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS392JunePerrittComment9 with:
"The Target Properties Sheet
with the specification of a Target's portal is just the entry point for a URC to get the
information to eventually construct a user interface that is tailored to the URC's capabilities and the user's preferences. For
each portal, a separate Socket Description (see INCITS 390-2004) describes the socket elements. One or more UIIDs/Presentation
Templates (see INCITS 391-2004) can plug into the socket
to give the portal a tailored user interface. The data may appear to be cryptic in these files since the labels and other
language-specific information are separated out into Resource Sheets (see INCITS 393-2004)."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS392JunePerrittComment10 with:
"We have divided the
specification of the URC framework into a family of 5 ANSI standard documents. (We would rather have one multi-part standard, but
this is not possible under ANSI.) INCITS 389-2004
provides an overview of the framework, and specifies requirements for the interaction between the components of the framework.
Session management happens as an interaction between the URC and the Target and is therefore described in INCITS 389. The
standards INCITS 390-393 each specify an XML-based language that
is used to build the components Socket Description, Presentation Template, TPS and Resource Sheet, respectively. Since these
languages are basically independent from each other and come with their own namespaces, we think that it is reasonable to define
them in separate standard documents. Thus if we want to
amend one of the languages we only have to update the relevant document without updating the others. Also, they are in separate
documents so that they can be used individually in other related application scenarios."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS392JunePerrittComment11 with:
"The <maxDistance> has been removed."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS392JunePerrittComment12 with:
"These elements can be
optionally used by a Target vendor to further describe some properties of a Target's portal. The Dublin Core Metadata Initiative
provides a set of properties that can be reused
across applications, to avoid having different names used for the same properties in different applications. The 4 properties
mentioned in section 7.10.9 are just examples out of the set of DCMI properties. <dc:identifier> can
contain a global product code pertaining to the portal, <dc:creator> the name or URI of the creator of the portal, <dc:publisher>
the name or URI of the publisher of the portal, and <dc:contributor> the name or URI of the
co-manufacturer of the portal. Such information can also be used in establishing trust."
The motion passed by unanimous consent.
MOTION (V2A) Comment INCITS392GottfriedZimmermannComment1 is accepted.
The motion passed by unanimous consent.
MOTION (V2A) Comment INCITS392GottfriedZimmermannComment2 is accepted.
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees to comment INCITS392PerrineRoucouxComment1 and will make appropriate changes.
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees to comment INCITS392PerrineRoucouxComment2 and will remove the <maxdistance> element.
The motion passed by unanimous consent.
MOTION (V2A) V2 accepts comment INCITS393GreggVanderheidenComment1 and will, in consultation with the commenter, work on a
solution.
The motion passed by unanimous consent.
MOTION (V2A) V2 accepts comment INCITS393EdPriceComment1 and will, in consultation with the commenter, work out a solution.
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS393EdPriceComment2 with:
"Yes, it is correct that
<uiidDescription> is a subelement of a <ResourceCollection>, but not a subelement of <ResourceSheet>. In other words,
<uiidDescription> and <ResourceSheet> are peers and both defined as subelements of <ResourceCollection>. Background: UIIDs can be
provided in any format, not necessarily text or XML based. They are typically language-independent. When interpreted or executed,
a URC may pick one or multiple resources to be bound to the UIID in order to construct the concrete user interface."
The motion passed by unanimous consent.
MOTION (V2A) V2 accepts comment INCITS393EdPriceComment3 and, in consultation with the commenter, will work out a solution.
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees to INCITS393EdPriceComment4 and, in consultation with the commenter, will work out a solution.
The motion passed by unanimous consent.
MOTION (V2A) V2 accepts comment INCITS393EdPriceComment5 and, in consultation with the commenter, will work out a solution.
The motion passed by unanimous consent.
MOTION (V2A) V2 agrees to comment INCITS393EdPriceComment6 and will make appropriate changes.
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS393JunePerrittCommment1 with:
"A resource itself is
static, but it can contain a reference to a socket variable (see section 8.4.4.4 The <value> element). Thus the content of a
(dynamic) socket variable can be bound to a resource."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS393JunePerrittCommment2 with:
"The table refers to the
label of the variable, not its value. We have changed the paragraph to say 'English label' to
help draw attention to this."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS393JunePerrittCommment3 with:
"We understand that more
examples are useful for understanding the URC framework. More samples are available in the 'V2 Simulation Environment' under
http://www.myurc.com/. Currently the XML documents of the following Targets are available there:
TV
VCR
TV/VCR combo
Lamp
Fan
Alarm clock
Coffee maker
Blinds"
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS393JunePerrittCommment4 with:
"Yes - the verbosity of XML
does make them look similar on the first glance. However, we wanted to contrast them to show how particular use cases would
be conveyed:
Example 1 and 3 reference their language context, but example 2 is valid for any language context.
Example 2 uses a value reference to provide a resource that is pertinent to one specific value of a variable.
Example 1 and 3 are pertaining to variables, not their values.
Example 1 and 3 use the role 'label', but example 2 the role 'help/purpose'."
The motion passed by unanimous consent.
MOTION (Vanderheiden/Sheppard): V2 respond to comment INCITS393JunePerrittCommment5 with:
"These properties have been
mentioned specifically to standardize usage of common properties for those resource providers that want to offer them. For
example, a URC may want to know the
creator of a Resource Sheet because it prefers resources from the target manufacturer to resources from 3rd parties or a
particular 3rd party."
The motion passed by unanimous consent.
MOTION (V2A) V2 accepts comment INCITS393GottfriedZimmermannCommment1 and, in consultation with the commenter, work out a
solution.
The motion passed by unanimous consent.
MOTION (V2A) V2 accepts comment INCITS393GottfriedZimmermannCommment2 and, in consultation with the commenter, work out a
solution.
The motion passed by unanimous consent.
MOTION (V2A) Noting that comment INCITS393GottfriedZimmermannCommment3 is a duplicate of
INCITS393GreggVanderheidenComment1, V2 accepts this comment and, in consultation with the commenters, will work out a solution.
The motion passed by unanimous consent.
No report.
No report.
No report.
No report.
No discussion on this item.
No discussion on this item.
No discussion on this item.
No discussion on this item.
MOTION (Price, Gilman) that the committee thank Perrine Roucoux for her service and excellant work for V2 over the past several years. In the formal discussion Gilman noted that Perrine added a touch of class to the proceedings and Price said we should do whatever we can to make sure that when Perrine returns she continues to work on V2.
Without objection the motion passed by unanimous consent.
ACTION ITEM (LaPlant) write a letter of commendation for Perrine Roucoux to the appropriate persons at NIST.
Hofstader said arrangements are being made and will furnish details.
No update.
No update.
No update.
REF:
http://www.itl.nist.gov/twiki/bin/view/NCITSV2/ActionItems
Plenary meeting #17 of V2 adjourned on October 5, 2004, at 03:34 PM (CT).