text:
I'm starting off 2014 with what I believe is a pretty exceptional rarity. Certainly it's one of the earliest commercial recordings of regional music from the highlands of Western Sumatra made by the Minangkabau people, known as Urang Minang in the local language. With most of the local recording industry at the time based in Java and Singapore, we are lucky that music of the Minang, a matrilineal, Islamic culture primarily based in the Minangkabau Highlands, was set to shellac. But more on that in a moment.
Traditional music practiced by the Minangkabau, or the "People of the Plains," is varied – there are classical songs for the bamboo flute (saluang), gong and drum ensembles (talempong) and numerous other types, and the music varies from the highlands to the coast. This track features the one-stringed rebab fiddle, the saluang flute, and the puput or pupuik, a rice-stalk reed instrument. There are three main styles of Sumatran rebab music: rebab pasisie, rebab piaman, and rebab darek. The first two are music of the coast, and the latter is inland rebab music. While I'm not certain which style this is, it's a lovely example of a kind of insistent and droning nature of Minangkabau music, with ornamented playing by the saluang and puput (one of which is very much in the distance), augmenting the string.
For the sake of documentation, I retained the original spelling on the label, though the Indonesian alphabet's spelling system was changed in 1947, following independence. The female singer, "Rapioen," would today be spelled "Rapiun." The title of the piece "Tandjoeng Sani" would be spelled "Tanjung Sani," which refers to a small village of the same name in Western Sumatra. The label also lists "Boekit Tinggi," which is the archaic spelling of the small city of Bukittinggi, formerly known as Fort de Kock, and where the musicians hailed from. "Djirek" in parentheses is the name of the 3-instrument ensemble – "Jirek" in today's spelling.
This piece was recorded in May 1939 by the Tjap Angsa (meaning "Swan Brand") label – it was recorded during their second recording session. According to the research by ethnomusicologist Philip Yampolsky, Tjap Angsa recorded most or all of their material in the city of Medan on the northern Sumatran coast, where they were partially based (their other headquarters was Bukittinggi). The label began in 1938 and issued several hundred discs, repressing some of them into the late 1940s. This disc was pressed in China, by the Chinese branch of EMI, who also supplied the engineers for the recording session.
While it would make sense for a Sumatran-based 78 label to record local musics such as those by the Minangkabau, other multinational labels did as well, for local distribution, including HMV, Columbia, and Odeon. Today, the Minang are a thriving culture of over 6 million with a very popular music scene (pop Minang is the name of the current genre). I don't want readers to exoticize this music to the point that they think the musicians must live in mud huts. That said, Minangkabau music constituted a definitively minor percentage of 78rpm releases when compared to the thousands of krontjong discs released, as well as other popular and traditional styles from the region. Today, in fact most all 78s from Southeast Asia are scarce, no matter what style you're talking about – even the full-fledged Western-style pop. I don't think that's going to change anytime soon – the tropics substantially increase the 78rpm attrition rate.
And this seems like the perfect time to bring up the recent release Longing For the Past: The 78 rpm Era in Southeast Asia, compiled and edited by my friend David Murray and recently issued on Dust-to-Digital. I've only mentioned it on the ES Facebook page, but I should state that it's one of the best looking and best sounding archival releases ever produced. I am biased – I provided some of my favorite rare Southeast Asian discs from my collection and did the transfers – but Dave, D-2-D and crew put an extraordinary amount of effort in that release. If you are interested in Southeast Asian music, you will truly appreciate it.
Label: Tjap Angsa
Issue Number: AM 28
Matrix Number: A6808
This post would just be a handful of sentences were it not for the published research of, and my correspondence with, Philip Yampolsky, as well as correspondence with Indonesian music historian Alfred Ticoalu.


text:
California Supply Chain Transparency Act
Chaco maintains high standards of business ethics and holds a deep regard for human rights. As corporate citizens, we strive to balance social and environmental standards with innovative business solutions. We recognize the importance of responsibly sourced products and are committed to working with supply chain business partners that are dedicated to safe, humane, and ethical working conditions that comply with international labor standards. We require the same from our business partners and have established guidelines to assist in our efforts to select partners who share our ethical commitments.
Pursuant to the requirements of the California Transparency in Supply Chains Act, Chaco makes the following disclosures of our efforts to eradicate slavery and human trafficking from our supply chain:
- Verification
Chaco conducts its own verification and utilizes third-party verification for our finish goods factories to assess risks related to human trafficking, slavery and other social compliance metrics.
- Auditing
Chaco engages an independent party to conduct announced audits of direct suppliers' facilities.
- Certification
Chaco requires direct suppliers abide by our Production Code of Conduct, which requires that our partners commit to upholding the human rights of workers, including not utilizing labor from victims of human trafficking or slavery, and that they share it with their contractors and subcontractors, requiring their adherence as well.
- Internal Accountability
Chaco maintains internal accountability procedures to ensure company standards on slavery and human trafficking.
- Training
Chaco trains its employees who are directly responsible for sourcing finished goods on mitigating the risk of slavery and human trafficking in our supply chain.

subset: commoncrawl


text:
Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document defines platform and language neutral programing interfaces that provide Web applications access to a hierarchy of dynamic properties representing device capabilities, configurations, user preferences and environmental conditions.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a W3C Last Call Working Draft of the Delivery Context: Client Interfaces (DCCI) 1.0 Accessing Static and Dynamic Properties specification, for review by W3C members and other interested parties. The Last Call review period ends on 27th July 2007 at 12:00 CET. Please send review comments before the end of the review period to firstname.lastname@example.com. This list is archived at http://lists.w3.org/Archives/Public/public-dcci-editors/. Following completion of Last Call, the Ubiquitous Web Applications Working Group plans to produce formal responses to all comments received by the Working Group and then advance the specification to Candidate Recommendation.
A single, normative change to this specification necessitated its republication. Subsequent to publication as a Candidate Recommendation, discussion with the DOM Interest Group (Member-only link) identified concerns about the DCCI interface inheriting from the DOM Node interface. Following the DOM IG's recommendation, the specification was modified to show DCCI inheriting from the DOM Element interface instead. This normative change has necessitated republication of the specification as a Last Call Working Draft. Consequently, this Last Call review is limited to this specific change in the specification. The Disposition of Comments from the previous Last Call is publicly available.
Publication as a Working Draft does not imply endorsement by the W3C 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.
This document is published as part of the W3C Ubiquitous Web Applications Activity by the Ubiquitous Web Applications Working Group. It is a deliverable as defined in the Charter of that group.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Introduction
1.1 Uses for DCCI
1.2 Reading the Specification
1.2.1 Conformance Information
220.127.116.11 Normative and Informative Parts
126.96.36.199 Normative Language for Conformance Requirements
1.3 Documentation Conventions
1.3.1 Bindings
1.3.2 Examples
2 Alternative Ways of Accessing the Delivery Context
2.1 Interfaces
2.2 Representations
3 DOM and the Data Model
3.1 Property Datatypes
3.1.1 DOM Basic Types
3.1.2 Additional Types
3.2 Property Interfaces
3.3 Property Collections
3.4 Property Initialization
3.5 Properties in Distributed Systems
3.6 Metadata
4 Processing
4.1 Querying and Searching
4.2 Using Events
4.2.1 Controlling Event Generation
4.2.2 Using DOM3 Event Groups with DCCI
4.3 Access Control
4.4 Errors
5 IDL Definitions for DCCI
5.1 The DCCIProperty Interface
5.1.1 IDL Definition
5.1.2 Attributes
5.1.3 Methods
5.2 The DCCIPropertyFilter Interface
5.2.1 IDL Definition
5.2.2 Attributes
5.2.3 Methods
5.3 The DCCIComponent Interface
5.3.1 Attributes
5.3.2 Methods
5.3.3 Exceptions
5.4 The DCCIException Exception
5.4.1 IDL Definition
5.4.2 DCCIException Error Codes
6 Event Processing Model
6.1 The DCCI-prop-change Event
6.2 How DCCI Uses Existing DOM Events
7 Conformance
7.1 Conformance Requirements for All DCCI Implementations
7.1.1 The DCCI Namespace
7.2 Additional Conformance Requirements for Implementations Based on DOM 3
8 ECMAScript Language Binding
8.1 DCCIException Interface
8.1.1 Properties of DCCIException:
8.2 DCCIProperty Interface
8.2.1 Properties of objects that implement the DCCIProperty interface:
8.2.2 Functions of objects that implement the DCCIProperty interface:
8.3 DCCIComponent Interface
8.3.1 Objects that implement the DCCIComponent interface:
8.3.2 Properties of objects that implement the DCCIComponent interface:
8.4 DCCIPropertyFilter
A IDL Definitions for DCCI
A.1 IDL for DCCI Implementations Based on DOM 2
A.2 IDL for DCCI Implementations Based on DOM 3
B Informative Use Case: Resolved Postal Code
C Normative References
D Informative References
E Changes Since the Previous Version
E.1 Normative Changes
E.2 Informative Changes
F Acknowledgements (Non-Normative)
This section is informative.
An ever increasing variety of devices with an increasing range of capabilities is gaining the ability to access the Web. This is providing the opportunity for the development of novel applications that are sensitive to such capabilities and can make use of them. Devices often keep a significant amount of information about their current operating state. Information, such as the current battery level, the ambient light level of the surroundings, the bandwidth available on the currently connected network and whether or not the user has muted audio output, is often available. The normal mechanism for accessing such information is via system-specific interfaces provided within the device. The interface described in this specification provides a more general mechanism that allows this kind of information to be made available to scripts running in Web pages within a browser on the device. Applications built using script-based techniques, such as AJAX [AJAX], have shown how dynamic capabilities can be included in Web pages. Scripts that use DCCI will also be able to use dynamic information about the device, network and user preferences to influence their behavior.
Not only has the proliferation of web-capable devices increased the range of capabilities available to users and application developers, it has also increased the diversity. For example, the smallest devices tend to have smaller displays and more limited keypads than their larger counterparts. Larger devices may have touch screens or even full keyboards. Knowledge of such properties can help authors tailor the operation of the user experience and the modality to suit the device. Additional information about user preferences and the surroundings in which the device is being operated can be used to enhance the user experience further.
The term delivery context[GLOSS] describes the set of characteristics of the device, the network, user preferences and any other aspects that apply to the interaction between a device and the Web. Some aspects of delivery context are static. For example, the color resolution of the display on a mobile device is fixed. Other aspects might be dynamic. Some devices have flip out covers that effectively provide a larger display when opened. Some devices can detect the orientation in which they are being used, and can rotate their output thereby changing the aspect ratio of the display. An increasing number of mobile devices can locate their position using the Global Positioning System [GPS]. Depending on the application in use, some or all of this information may be useful in tailoring the user experience[GLOSS].
Generally, properties are considered highly dynamic if their values can change during a session with a web server. Location is a good example of a property that can be highly dynamic with values being transmitted through mechanisms such as GPS notifications (see for example[LIF] ). Other properties may have values that can change, but more slowly. In particular, there are properties that are usually constant during a session. User preferences often fall into this category. This second kind of less dynamic property is often associated with some kind of fixed, default value. For example, a device may be manufactured with a particular font as default. A user can subsequently change this default font. Although the value of the characteristic has been changed and may affect the rendering of web pages, the value is unlikely to be highly dynamic.
DCCI can provide access to any part of the delivery context available at the device. This includes static properties, those that change infrequently and those that are highly dynamic, such as battery level or location.
The key uses for DCCI are related to adaptation[GLOSS]. One major use is in supporting devices that are capable of interaction with users in a variety of modalities[GLOSS]. For example, a device may be able to interact visually, or using voice, depending on the user's current context.
The W3C Multimodal Interaction Framework [MMI] identifies the core components for multimodal systems. At its heart, lies the Interaction Manager [IM], which coordinates data and manages execution flow from various input and output modalities. DCCI can provide the Interaction Manager with dynamic access to the properties that represent the current delivery context. This can include the properties of the device and of the network and user preferences. These properties can indicate which modalities are supported and which are currently active. The DCCI can retrieve this information and, additionally, can provide a means to enable or disable particular modality functions. It also provides notifications when properties change. Such changes might occur as a result of a user action and might indicate that a user now prefers a different modality to be used.
In providing mechanisms to query and update delivery context properties, and to report changes via events, DCCI directly supports the basic W3C Multimodal Interaction Requirements [MMIReqs] (MMI-G14, MMI-G15, MMI-A4).
Another major use for DCCI relates to content adaptation for device independence. Materials to be used on a particular device may need to be tailored to take account of that device's particular capabilities. Layout, styling and the media associated with a web page may all need to be tailored based on the delivery context to achieve a good user experience. Where the tailoring is based on dynamic properties, it may be necessary to provide adaptation capabilities on the client. In this type of scenario, DCCI provides an interface that can be used to access the delivery context in support of highly dynamic adaptation.
The normative and informative parts of this specification are identified by use of labels within various sections. Generally, everything in the specification is considered to be normative, apart from the examples.
Individual conformance requirements or testable statements are identified in the DCCI specification by the use of specific key words. In particular, the key words must, must not, required, shall, shall not, should, should not, recommended, may, and optionalin this specification are to be interpreted as described in [IETF RFC 2119] .
This specification provides a normative definition of the interface based on OMG IDL [IDL].
In addition, it also provides a normative ECMAScript [ECMAScript] binding.
Examples given in this specification are informational. The markup used in examples is XHTML 1.0. The script used in the examples is JavaScript.
This section is informative.
DCCI provides one particular way of accessing delivery context. It is particularly suitable for use within web clients. Other mechanisms are available for use in different circumstances. Two general mechanisms exist for delivery context access. One is based on the specification of programming interfaces. The other is based on specific representations of the delivery context.
Interfaces provide a way to access delivery context information regardless of the way that information is actually stored and represented. This can be important for use on clients, particularly when implementations may have to execute on devices with restricted memory, processing power and battery life. Interfaces are also important for server-side implementations. A number of vendor-specific representations of delivery context are now in existence. Standardized interfaces can provide common mechanisms that can be used by authors regardless of the particular representation in use.
DCCI is an interface that focusses on making properties from the delivery context available to code executing within a web client[GLOSS]. Other interfaces focus on making similar information available to code executing within web servers[GLOSS].
Some of these server-side interfaces are primarily concerned with static information. This comprises the subset of the delivery context that is common to all instances of a particular device. The W3C Mobile Web Initiative's Device Description Working Group [DDWG] is developing a standardized interface suitable for accessing this kind of information.
Other interfaces are more concerned with dynamic and highly dynamic properties. The Open Mobile Alliance [OMA] is working on standardization of this style of interface in the Device Capabilities sub-working group of its Browser Technologies working group [BT DCAP].
One set of interfaces is specifically oriented at providing access to the delivery context directly from markup languages. The Delivery Context: XPath Access Functions [XAF] provides access to the delivery context from XPath expressions, which can be embedded in markup languages.
Prior to the work in defining interfaces, previous standardization work concentrated on defining representations of the properties of the delivery context. In particular, W3C's Composite Capability/Preference Profiles [CCPP] provides a framework for representations of delivery context properties. It is based on the Resource Description Framework [RDF]. CC/PP does not itself specify a particular vocabulary and so does not provide a representation of the delivery context. However, it provides the framework on which such representations can be built.
By adding a specific vocabulary to CC/PP, the OMA's User Agent Profiles (UAProf) specification [UAPROF] does provide a representation of delivery context. Typically, UAProf tends to be used to represent rather static properties of the delivery context. UAProf profiles are normally associated with a URI. A profile needs to be accessed, parsed and analyzed to allow the information about properties to be retrieved.
This section is informative.
DCCI defines an interface for accessing delivery context. It does not mandate any specific data model for the delivery context. As such, it can provide a layer of insulation from specific implementations and data models. DCCI does, however, assume that the overall form of the delivery context is a hierarchy. A number of existing delivery context data models are hierarchies. For example, UAProf has a hierarchical arrangement of properties, as does the W3C's Delivery Context Ontology [DCOnt].
DCCI also needs to provide an eventing model, which can be used to report changes dynamically. Situations such as the battery level falling below a certain value or a change in a user preference must be able to cause an event to be triggered, notifying code that has registered an interest in changes in the property.
The Document Object Model (DOM) (see for example [DOM]) provides a mechanism suitable for use on web clients that can support hierarchical data models. It also provides an eventing model. DOM implementations are already available in browsers that support scripting. DOM provides the two key features needed by DCCI. By basing DCCI on DOM, and reusing its capabilities, it is also possible to minimize the additional resources that are needed in order to access the delivery context. This is important in the context of small, mobile devices which may have significant limits in the available resources.
For these reasons, DCCI is defined as an extension to the DOM. The delivery context is represented as an instance of the DOM. This instance is completely separate from the DOM instance used by the browser to represent the web page that is providing the user experience. They have different root elements.
To maximize the range of situations in which DCCI can be used, DCCI implementations may be based either on DOM 2 (see for example [DOM2-Core]) or on DOM 3 (see for example [DOM3-Core]). Some browsers support DOM 2 and some support DOM 3. While there are some differences in the level of DCCI capability that can be achieved with these two versions of DOM, the increased variety of devices that can be accommodated by supporting both is considered worthwhile. DCCI provides a mechanism that allows the type of support available to be determined by code that uses it.
One important addition, available when DCCI is based on DOM 3, is that XML Namespaces [XML-Namespaces] can be used. Namespaces allow clear distinction between different properties in the delivery context that might have arisen in different ontologies or that might be provided by different organizations.
Because namespaces are not available in DOM 2, there is an increased risk
of name collisions. As a consequence, where this specification reserves a
name it specifies a prefix of
DCCI- to try and help avoid such
DCCI represents delivery context properties as nodes that extend the DOM
Elementinterface. The ways in which property values can be
accessed and in which notifications can be received, when changes to
properties occur, are described later in this document. The way in which the
version of DOM being used affects the available capabilities of DCCI is also
Figure 1. An example of a possible hierarchy of properties that could be accessed via DCCI.
Figure 1 illustrates a hierarchy of delivery context properties. The property labelled Delivery Context Root provides the root of the tree. A number of other properties are shown, some of which are leaves of the tree. In the figure, the ellipses (...) indicate locations where there might be additional sets of properties. The properties shown in Figure 1 are illustrative on the typical kind of information that might appear in ontologies such as [DCOnt]. The leaf nodes in the tree are typically properties whose values are of interest to users of the DCCI.
Each property in the delivery context is associated with a given datatype. Individual properties may , for example, be numbers or strings.
DCCI supports properties with any of the following DOM datatypes (see [DOM2-Core] and [DOM3-Core]).
This type represents values that can be either
This type represents a string as a sequence of 16 bit units encoded in UTF-16.
In addition, if the implementation is based on DOM 3 [DOM3-Core], DCCI also supports the following additional datatypes:
This type represents an object in the scripting language being used to access the interface.
In addition to the DOM types, DCCI also defines the following additional types:
This type represents values that can be of any type. Specifically,
for implementations based on [DOM2-Core]
this is actually a
DOMString. For implementations based on
[DOM3-Core] it is a
Some DOM operations return individual items in the form of a DOM
Node. Where such an item represents a property of the
delivery context, the
Nodewill actually be a
Some DOM operations return collections of information rather than
individual items. When this happens, the collection is in the form of a
NodeList. Where such a collection represents a set of
delivery context properties, each
Node in the NodeList
will actually be a
DCCI provides mechanisms to access properties within the delivery context. It does not provide the means by which properties in the delivery context are managed. Implementations of DCCI must provide those facilities by whatever means is appropriate. Properties may be added and removed from the delivery context at any time in response to events external to DCCI. For example, new properties may appear in the delivery context when a user enables a particular function in their device. Property values may also change at any time, of course.
The mechanisms by which implementations of DCCI manage properties and their values within the delivery context is out of scope for this specification.
In some contexts, devices may take part in networked interactions with other devices. In such cases, some aspects of the delivery context may represent properties associated with those other devices or on servers that are also part of the network. For example, where a device is connected in some way with a printer via an intervening network, the delivery context might contain properties that indicate the toner or ink levels available in the printer. Where the delivery context includes information that is not directly held on the device on which DCCI is executing, there may be network delays involved in accessing the information. Implementations should ensure that delays in accessing such information do not cause applications using DCCI to block for long periods of time.
The mechanisms and network protocols used to distribute and synchronize delivery context properties between devices and other network components are outside the scope of this specification. Some possibilities include SIP Events [SIP], Web Services, and technologies such as Universal Plug and Play [UPnP].
Metadata can be directly or indirectly associated with any property accessed via DCCI. Some potential examples of metadata include the version of a property interface, and timestamps for property creation and modification. Richer metadata could describe ontologies of properties, and be expressed using powerful metadata frameworks like OWL [OWL] for the purposes of authoring solutions.
DCCI provides mechanisms for accessing the metadata associated with a
property. However, the details of the particular kinds of metadata used and
their representation is outside the scope of this specification. The
mechanism for accessing property metadata is based on the
DCCIMetadataInterface and
properties associated with each delivery context property. The first of these
properties provides access to the metadata-related information while the
second defines its datatype. As an example, a DCCI implementation might
choose to provide metadata via a URI represented as a DOMString. In this
DCCIMetadataInterface would hold the URI and
DCCIMetadataInterfaceType would indicate that the type was
DOMString. As an alternative, the implementation of a particular property
could return an interface as the value of
Operations on that interface would then yield the metadata.
These properties are described fully in 5.1 The DCCIProperty Interface.
This section is informative.
Values of delivery context properties may change at any time. For example, a user may choose to enable a particular function on the device. Equally, the set of properties in the delivery context may also change. If some optional module, such as a camera, is plugged into a device, a new set of properties may become available. In this example, these new properties might include the number of bits per pixel supported by the camera and whether or not it can capture video.
DCCI supports dynamic access to the delivery context. In particular it provides interfaces that allow code to:
query the value of properties within the delivery context
subscribe to notifications about changes to properties
unsubscribe from notifications about changes to properties
These interfaces not only allow access to delivery context properties at any point in time, they also allow notification when properties change.
DCCI supports direct access to the properties in the delivery context
through the
searchProperty() method in the
DCCIProperty interface. This method
provides direct access to a specific property when both the namespace and
property name are supplied. However, it can also provide access to sets of
properties if wild cards are used. For example, suppose that part of the
delivery context is the tree shown in Figure 2.
Figure 2. An example property hierarchy.
In Figure 2, there are two cameras associated with the device. One is in a namespace represented in the figure by the prefix base. The other is in the namespace represented by the prefix acc. This might represent the situation where a more capable camera module has been plugged in as an accessory to enhance the capabilities of the device.
The value of the property BitsPerPixel for the accessory camera could be retrieved by using a query that explicitly references the name BitsPerPixel and the namespace associated with the prefix acc. A query that merely referenced the name and used the wildcard * for the namespace would retrieve a list containing both values. Searching such as this may be valuable when the content of the delivery context is highly dynamic and its structure is not completely predictable.
In fact, of course, searches like this might actually retrieve other properties also called BitsPerPixel. Other components of the device, such as any displays that it has, might also have properties with this name. Ontologies of delivery context properties try to address such ambiguity by defining unique property names.
Full details of the function available for querying and searching for
property values are given in the section on the
searchProperty() method in the
DCCIProperty interface.
DCCI implementations provide events that can be used as notifications that
changes have occurred in the delivery context. In addition to the usual DOM
events, which can, for example, indicate changes in the structure of the
delivery context as properties are added or removed, DCCI adds a new DOM
Event, with a value of
DCCI-prop-change. This event is
raised when a property changes value.
DCCI does not define any additional specific events to report particular situations that may be associated with specific properties. Examples of situations include:
an alert to indicate that the battery level in the device is low
an alert to indicate a loss of connectivity to the network
an alert that the performance of speech recognition has fallen below some predefined quality threshold
DCCI implementers are expected to use the available DOM and DCCI events with appropriate data to indicate such situations.
The conditions under which an event is raised may vary. Property change events, in particular, may be generated frequently for rapidly changing properties. For some properties, it may be useful to control the conditions under which notifications are generated, in order to avoid the need to raise and process excessively large numbers of events. Control of the conditions under which events are generated can be exercised, in DCCI, through the values of subproperties of a property or through associated metadata.
As an example, consider the case of location updates being generated by the built-in GPS feature in a mobile device. For some applications, it may be necessary for every change in position, reported by the GPS, to be reflected immediately in the delivery context. However, this can result in a very large number of events being raised and processed. For many applications, such as those that add a real time track to a map display, it may be better to report changes only when the device has moved by at least a minimum distance, which could be related to the scale of the map itself. This could bring a very significant reduction in the amount of event processing that has to take place.
DCCI does not define any specific properties or metadata to be used for controlling event generation. However, it does provide the basic facilities that can be used to enable this function.
Event groups can be used to prevent listeners from stopping an event's propagation before other listeners have a chance to react to it. Event groups may be available in implementations of DCCI that are based on DOM 3.
The DOM 3 Events specification [DOM3-Events] notes that if two listeners are registered in two different groups one cannot prevent the other from being triggered. This feature is useful when multiple modules are listening to the same event and some of them need a guarantee that they will receive it, regardless of the actions of other listeners in other groups, which may cause propagation to cease.
An event category is represented by a namespace URI and a local name. Event categories allow listeners to be registered for a hierarchy of DCCI events rather than for a specific event type. For example, events denoting an automatic speech recognition (ASR) connection status could be associated with the following three categories:
{"http://www.example.org/2003/voicexml", "connection"}
{"http://www.example.org/2003/voicexml", "connection.disconnect"}
{"http://www.example.org/2003/voicexml", "connection.disconnect.hangup"}
These particular examples are based on the VoiceXML specification [VoiceXML].
An event listener that wishes to be notified on the overall status of an ASR connection would register for the first category of events. As a result, it would be notified when the ASR engine is connected and when it is disconnected. In addition, it would be notified specifically when the disconnection was due to a hangup.
A different listener, that is only interested in notifications on hangup, would register for the last event category in the example.
DCCI implementations may provide similar capabilities to group events when based on DOM 3.
DCCI provides the means for accessing the delivery context, which includes information such as user preferences, device characteristics and environmental factors. Some of this information could be considered sensitive. As a consequence, a form of access control would be desirable to protect such information.
The definition of the details of such access control capabilities is
outside the scope of DCCI. However, where an implementation provides access
control and an access violation is detected, the exception
DCCIException with error code
ACCESS_VIOLATION_ERR must
be raised.
In general, DCCI operations return values that may indicate error conditions. In "exceptional" circumstances, DCCI operations may raise exceptions, for example, when an operation is impossible to perform.
This section is normative.
This section specifies the DCCI in terms of normative IDL definitions for its properties, interfaces and exceptions. It also defines the behavior of the DOM interfaces associated with DCCI.
The Delivery Context Client Interfaces are formally defined in terms of
OMG IDL [IDL] interfaces. The
DCCIProperty represents an element (property) in the DCCI tree.
DCCIProperty interface inherits
from the DOM
Element interface. It is required to implement the
EventTarget interface. It provides support for creating and
manipulating a hierarchy of properties. Unless specifically stated otherwise,
the behavior of DCCI is the same as that of DOM. Within the DCCI context, the
DOM Node that is returned through the DOM
method call should be interpreted as a
DCCIProperty. The
DCCIComponent, the Root Property in Figure 1, is itself a
property element with an additional read-only attribute for the DCCI version
number. For DOM conformance details see section 7 Conformance.
Properties raise events to notify changes in property values, or the
removal or addition of properties themselves.
supports methods for adding and removing event listeners. The
DCCIProperty supports the event capture/bubbling model. This
allows an event listener to be added at different levels of the property
hierarchy. This is independent of the event propagation model in the host
DCCI conforms to the naming conventions for property names and namespaces adopted by XML [XML] and RFC2396 [RFC2396], respectively. In case those conventions are not respected, the standard DOM exceptions must be raised.
interface DCCIProperty : Element { //Attributes attribute any value; readonly attribute DOMString valueType; attribute DOMString propertyType; readonly attribute boolean readOnly; readonly attribute DOMString DCCIMetadataInterfaceType; readonly attribute any DCCIMetadataInterface; //Methods boolean hasProperty(in DOMString namespaceURI, in DOMString propertyName, in boolean deep) raises(DCCIException); NodeList searchProperty(in DOMString namespaceURI, in DOMString propertyName, in DCCIPropertyFilter dcciPropertyFilter, in boolean deep) raises(DCCIException); };
The DCCIProperty interface makes specific use of the following attributes
tagNameof type
tagName attribute associated with a
DCCIProperty must hold the name of the property.
DCCIProperty interface exposes the following attributes
in addition to those of
value of type
This attribute holds the value of the property.
Note that the
value attribute does not override the
nodeValue attribute that
inherits from
Node via
Element. The
nodeValue property can only hold values of type
DOMString, which is insufficient for the needs of
DCCIProperty. In a
DCCIProperty, the value of
nodeValue attribute should be
DCCIProperty nodes may not have a value. Examples
include nodes that simply provide containers for sets of other
properties. The Display property in Figure 1 might be such a property.
In these cases, the value of the
value attribute must be
valueType of type
DOMString, readonly
This read-only attribute describes the type of value that the
property contains in its
value attribute. Applications can
read the
valueType attribute to determine the type and the
format of a property value present in the
value attribute.
The values for
valueType are dictated by the properties
and are defined by property vendors or other bodies.
To avoid name clashes, the value of
valueType should be
a URI.
For string values, the value type must contain the string "DOMString".
of type
propertyType attribute denotes the type of
property that the
DCCIProperty Interface references. The
propertyType attribute provides an additional level of
granularity to the DCCI interface. This allows the extension of the
DCCIProperty interface for a particular type of property.
propertyType attribute is a read-only attribute of
type DOMString. For example, a presentation property description can
describe additional interfaces for the DCCI presentation property that
would be needed to access additional screen specific properties. For
example, the
DCCIPropertyType for such an interface could
be the string "DCCIPresentationType".
propertyType values and corresponding
DCCIProperty interface extensions will be specified by
other groups/vendors and is outside the scope of the current
specification. The default value for the
attribute is the
null value.
readonly readOnly
of type
boolean, readonly
readOnly attribute is used to determine whether
value and
propertyType attributes can be
modified. When
readOnly is true, any attempt to modify the
value and
propertyType attributes will result
in a DOMException being raised with a
NO_MODIFICATION_ALLOWED_ERR error code. When
readOnly is set to false the
value attribute
may be changed.
DCCIMetadataInterface of type
This attribute defines metadata associated with the property. The value of this attribute might be data associated with the metadata, or it might be an interface by which that metadata can be accessed.
The related attribute
DCCIMetadataInterfaceType defines
the type associated with
The details of the
DCCIMetadataInterface interface
depends on its type, which is implementation specific.
For example, the
DCCIMetadataInterfaceType for a
property could be set to "application/rdf+xml", and the value of the
DCCIMetadataInterface could be a URI that points to the
RDF meta data information available for this property. This interface
allows a script author to recognize the MIME type contained within
DCCIMetadataInterfaceType, and then fetch and process the
RDF meta data at the URI contained in the
See 7 Conformance for more
implementation details regarding
DCCIMetadataInterfaceType of type
This attribute defines the type of the
The DCCIProperty interface exposes the following methods in addition to those of DOMElement.
This method is used to determine whether this property has the specified property, as identified by name and namespace URI, amongst its descendants. The search for a property matching the criteria can include all descendents of the property, or can be restricted to its immediate children.
namespaceURI parameter is a
DOMString containing the URI of the namespace
of the property for which the search is being carried out.
namespaceURI is specified as the string "*"
it denotes that properties in any namespace satisfy the
propertyName parameter is a
DOMString containing the name of the property
for which the search is being carried out. If the
propertyName is specified as "*", it denotes
that properties with any name satisfy the search
deep is set to
the search applies to all of the descendents of the
property. When it is set to
false, the search
is limited to the property's immediate children.
An implementation that supports access control must exclude properties from the search, if the invoker of this method does not have the appropriate access rights.
The return value is
true if one or more
properties match the search criteria. It is
This method does not generate any exceptions.
This method is used to retrieve one or more properties that are descendents of the property. Properties are retrieved based on the specified name and namespace URI. The search for properties that matching the criteria can include all descendents of the property, or can be restricted to its immediate children.
This method also provides a way to filter the resulting list of descendent properties, using an application-defined filter.
namespaceURI parameter is a
DOMString containing the URI of the namespace
of the property for which the search is being carried out.
namespaceURI is specified as the string "*"
it denotes that properties in any namespace satisfy the
propertyName parameter is a
DOMString containing the name of the property
for which the search is being carried out. If the
propertyName is specified as "*", it denotes
that properties with any name satisfy the search
dcciPropertyFilter parameter
specifies a filter of type DCCIPropertyFilter which can
determine whether each node that passes the name/namespace
criteria should be included in the final
NodeList returned by the method. If this
parameter is specified as
null, no filter is
deep is set to
the search applies to all of the descendents of the
property. When it is set to
false, the search
is limited to the property's immediate children.
An implementation that supports access control must exclude properties from the search, if the invoker of this method does not have the appropriate access rights.
This method returns a
NodeList consists of an ordered collection of
DCCIPropertynodes. The
NodeList has an
integer attribute "length" that gives the number of
DCCIProperty nodes it contains. If no properties
matched the search criteria, the resulting
will have a
length attribute value of zero.
This method may raise the following exceptions.
PROPERTY_FILTER_ERRerror code
ACCESS_VIOLATION_ERRerror code
interface DCCIPropertyFilter { //Methods boolean acceptProperty(in DCCIProperty property) raises (DCCIException); };
The DCCIPropertyFilter interface does not expose any attributes.
The DCCIPropertyFilter interface exposes the following method.
This method is called by the DCCI implementation to check whether
a property node can be included within a
NodeList. If the
return value is
true, the node is included, otherwise the
node is rejected. The application author provides the implementation
for this method. It can contain any appropriate filtering criteria for
Node. Only those properties which satisfy the
criteria implemented within the
acceptProperty method will
be included in the
NodeList by the DCCI implementation.
This is the
DCCIProperty node that will
be passed to
acceptProperty by the DCCI
implementation to check if the node should be accepted to
be included within the
The return value is
true if the DCCIProperty
passed in in the
property parameter is accepted by
the filter. It is
false otherwise.
Properties accepted by the filter will appear, for example, in
the output of a call to
searchProperty in the
This method may raise the following exceptions.
PROPERTY_FILTER_ERRerror code
DCCIComponent interface forms the root node of the DCCI
DCCIComponent derives from the
DCCIProperty interface and contains an additional read-only
attribute called
version. The value of the
attribute is the version number of the Delivery Context: Interfaces
component. The value of
version for this release is the string
"1.0". The
parent and
value attributes of a
DCCIComponent have the value
The DCCIComponent interface adds a single attribute to those from the
DCCIProperty interface from which it inherits. In addition, the
value attribute of DCCIComponent interfaces must be
version of type
Identifies the version number of the DCCI specification that has been implemented. The version number for this specification is "1.0".
This interface does not define any additional methods.
This interface does not define any additional exceptions.
DCCI defines one specific additional exception, named
DCCIException, in addition to those that can defined by the DOM
exception DCCIException { unsigned short code; }; //Exception codes const unsigned short ACCESS_VIOLATION_ERROR = 1; const unsigned short NOT_SUPPORTED_ERROR = 2; const unsigned short PROPERTY_FILTER_ERROR = 3;
The following error codes can be returned with this exception.
This exception is raised if an implementation of DCCI, that supports access control, detects an illegal attempt to access the delivery context.
This exception is raised if a call is made to a method which is not supported by DCCI. In particular, a number of standard DOM interface methods are not supported by DCCI. Invocation of these methods must return this error code.
This exception is raised if a property filter performs an invalid or illegal operation when filtering a list of nodes returned during a search operation.
This section is normative.
The DCCI event model conforms to the DOM Event Specification. This
includes support for the capture and bubble phases. Modules that implement
the DOM
EventListener interface, such as a browser or an
Interaction Manager [IM], can register as listeners on
the DCCI tree. Concurrent with the DOM Event propagation algorithm, when a
DOM Event is dispatched on the DCCI property tree, listeners registered for
this event type get activated. The listener receives a DOM Event object type
that may need to be copied or appropriately cast before it can be processed
by that listener (if that listener cannot directly process DOM Events).
In addition to using existing DOM events to signal particular occurrences, DCCI also defines one new event.
DCCI raises this event to notify a change in the value of a property. This
event is a normal DOM
Event with its
type attribute
set to
DOMString literal value
Where an implementation is based on DOM 3, it must mark the event
as being within the DCCI namespace. In
particular it must set the
namespaceURI attribute of the
Event to that of the DCCI
DCCI uses existing DOM events (see for example [DOM2-Events]) to notify listeners about particular changes in the structure of the DCCI DOM. In particular DCCI implementations must use the following DOM Mutation events to notify listeners about insertion of items into the DOM and about their removal.
This event is raised when a new property has been added to the DCCI DOM. The event is dispatched after the new node has been inserted. The target node of this event is the property being inserted.
This event is raised when an existing property is being removed from the DCCI DOM. The event is dispatched before the property is removed from the tree. The target node of this event is the property being removed.
This event is raised when the structure of the DCCI DOM changes in any way. Listeners can use it instead of the more specific events concerned with node insertion and removal. Depending on the nature of the change being made, implementations may choose to raise it after a single modification has been made to the DCCI DOM. Alternatively, implementations may choose to raise it only after a set of modifications has been applied. This latter case can accommodate situations in which multiple changes occur in rapid succession.
The target of this event is node that is the lowest common parent of the changes which have taken place. This event is raised after any other events caused by those changes have been raised.
This section is normative. It gathers together the conformance requirements for implementations of DCCI defined in this specification.
A conforming DCCI implementation must implement all the normative sections of this document.
A conforming DCCI implementation must implement the DOM
EventTarget interface [DOM2-Events].
In a conforming DCCI implementation, the DCCIProperty interface must inherit from the DOM Element interface.
A conforming DCCI implementation must support the use of the
isSupported()method, in the DOM
Node interface, to
enable code to determine the level of DOM used in the implementation of DCCI.
Specifically, the following results must be supported by conforming
isSupported() on any DCCI node with the
feature parameter set to "DCCI-DOM" and the version set to "2.0"
must return
true if the implementation of DCCI is
based on DOM 2 and
false otherwise.
isSupported() on any DCCI node with the
feature parameter set to "DCCI-DOM" and the version set to "3.0"
must return
true if the implementation of DCCI is
based on DOM 3 and
false otherwise.
A conforming DCCI implementation must support all datatypes specified by the W3C DOM 2 specifications [DOM2-Core]
In a conforming DCCI implementation,
DCCIProperty nodes
must return
ELEMENT_NODE as the value of their
nodeType attribute.
In a conforming DCCI implementation,
DCCIProperty nodes
must return the name of the property as the value of their
nodeName attribute.
A conforming DCCI implementation must raise the DOM
ACCESS_VIOLATION_ERR Exception if it supports access control and
detects an access violation.
A conforming DCCI implementation must raise the DCCI
NOT_SUPPORTED_ERR Exception if an operation is requested that it
does not support.
A conforming DCCI implementation must raise the DOM
NO_MODIFICATION_ALLOWED_ERR Exception if an operation is
requested that would result in a disallowed modification of the delivery
A conforming DCCI implementation must raise the DOM
NOT_SUPPORTED_ERR Exception when an attempt is made to insert
nodes with types other than
DCCIProperty into the DCCI DOM. In
particular, this applies if the DCCI implementation also supports the methods
replaceChild(), and
appendChild() in the
DOMElement interface.
In a conforming DCCI implementation,
DCCIProperty nodes
may return
null for the value of the
ownerDocument attribute.
A conforming DCCI implementation must implement
DCCIMetaDataInterface as a
DOMString unless the
implementation is based on DOM 3, in which case it must be implemented
as a
A conforming DCCI implementation may implement cloning, adopting
and importing of nodes. However, it must raise a DOM
NOT_SUPPORTED_ERR Exception for any operation of these
operations that is not supported.
A conforming DCCI implementation should raise the most appropriate
Exception when it encounters an error not otherwise
stipulated explicitly in this specification.
A conforming DCCI implementation may provide access to the root of
the delivery context through a global variable. If this mechanism is chosen,
the preferred name for the variable is
DCCI implementations must use the DOM Mutation events
DOMNodeRemoved and
DOMSubtreeModified to notify listeners about changes in the
structure of the delivery context.
The DCCI namespace URI is
In addition to the conformance requirements for all DCCI implementations, additional requirements apply to those implementations based on DOM 3.
A conforming DCCI implementation based on DOM 3 may support the use
of the
DOMImplementationRegistry to enable the DCCI
DOMImplementation to be discovered. If this approach is used,
the implementation must be identified by the DOMString literal value
"DCCI 1.0". Additionally, if this approach is used, the
implementation must provide access to the root of the delivery context
using the
getFeature() method of the
DOMImplementation interface with the feature parameter set to
DOMString literal value
"DCCI-Root" and the
version set to the
DOMString literal value
A conforming DCCI implementation based on DOM 3 must support all the datatypes supported by the W3C DOM 3 specification [DOM3-Core].
In a conforming DCCI implementation based on DOM 3
DCCIProperty nodes must return the value of their
textContent attribute as
A conforming DCCI implementation based on DOM 3 must implement
DCCIMetaDataInterface as a
A conforming DCCI implementation based on DOM 3 may implement the event interfaces described in the [DOM3-Events]. Note that [DOM3-Events] adds the notions of event namespace, groups and categories to [DOM2-Events]. These may be useful features in the context of DCCI.
A conforming DCCI implementation based on DOM 3 must support the use of namespaces in events to distinguish between DCCI events raised by different properties. This allows events that have the same name but which were defined by defined by different organizations to be distinguished. They also allow code to listen for property events only from a particular organization.
This section is normative. It describes an ECMAScript [ECMAScript] language binding for DCCI.
The type of the
value and
attributes, specified below, depends on the version of the DOM used: for DOM
level 2, the type is
String. For DOM level 3, the type is Object
(ECMAScript binding equivalent of DOM3 DOMObject)
The value of the constant
ACCESS_VIOLATION_ERR is
The value of the constant
NOT_SUPPORTED_ERR is
The value of the constant
PROPERTY_FILTER_ERROR is
Objects that implement the
DCCIProperty interface have all
properties and functions of the
EventTarget and the
Element interfaces as well as the functions and properties
defined below:
DCCIProperty interface:
This property is of type
String for DOM2, or
Object otherwise.
This read-only property is a
This property is a
This read-only property is a
This read-only property is a
This read-only property is of type
String for DOM2,
Object otherwise.
DCCIProperty interface:
searchProperty(namespaceURI, propertyName,
dcciPropertyFilter, deep)
This function returns a
The namespaceURI parameter is a
The propertyName parameter is a
The dcciPropertyFilter parameter is a
The deep parameter is a
hasProperty(namespaceURI, propertyName,
This function returns a
The namespaceURI parameter is a
The propertyName parameter is a
The deep parameter is a
DCCIComponent interface:
Objects that implement the
DCCIComponent interface have all
properties and functions of the
DCCIProperty interface as well as the
property defined below.
DCCIComponent interface:
This read-only property is a
This is an ECMAScript function reference. The method takes in a DCCIProperty object as parameter and returns a boolean value.
This appendix contains the complete OMG IDL [IDL]
definitions for DCCI, with the exception of existing DOM modules for the DOM
core and DOM
events, which are used for some common DOM data types and the
EventTarget interface.
// File: DCCI.idl #include "dom.idl" #include "events.idl" #pragma prefix "dom.w3c.org" module dcci { typedef dom::DOMString DOMString; typedef dom::DOMString any; typedef dom::Element Element; typedef dom::NodeList NodeList; typedef events::EventTarget EventTarget
interface DCCIComponent : DCCIProperty { readonly attribute DOMString version; };
interface DCCIPropertyFilter { boolean acceptProperty(in DCCIProperty property) raises DCCIException; } ;
interface DCCIProperty : Element { attribute any value; // raises(DCCIException) on setting // raises(DCCIException) on retrieval readonly attribute DOMString valueType; attribute DOMString propertyType; readonly attribute boolean readOnly; // used for direct association of metadata readonly attribute any DCCIMetadataInterfaceType; readonly attribute any DCCIMetadataInterface; // a pair of convenience functions that save // having to explicitly walk the propertytree NodeList searchProperty( in DOMString namespaceURI, in DOMString propertyName, in DCCIPropertyFilter dcciPropertyFilter, in boolean deep) raises(DCCIException); boolean hasProperty( in DOMString namespaceURI, in DOMString propertyName, in boolean deep); }; }
The IDL for DCCI implementations that are based on DOM 3 is identical to
that described in A.1 IDL for DCCI
Implementations Based on DOM 2 except for the definition of the
any type. For DOM 3 based implementations, this type is defined
typedef dom::DOMObject any;
This section is informative. It provides an illustration of how the DCCI could operate.
This example demonstrates how events can be used. In this example location events are provided whenever the device has moved a certain distance. The location may be determined by GPS, or via a location based service.
Three DCCI properties are used in this example:
updateDistance and
format. The
location property contains the current location in the form
specified by the
format property. The
updateDistance property is used by the implementation to
determine when to trigger the update event. This reduces the number of events
being triggered, as postal codes are often quite large and as such it would
be inefficient to have more frequent events triggered. This is an example of
how conditional events can be implemented via an additional property.
This section describes the changes introduced in this version of the specification.
A single, normative change to this specification necessitated it's republication. Previous versions of the specification defined the DCCI interface as inheriting from the DOM Node interface. However, subsequent to completion of the transition to Candidate Recommendation, discussion of this aspect of the specification with members of the DOM Interest Group caused this decision to be re-evaluated.
In accordance with the recommendations of the DOM Interest Group, the DCCI specification has been rewritten to show DCCI inheriting from the DOM Element interface, rather then the DOM Node interface. This entailed making a significant number of editing changes throughout the document.
In addition to correcting minor typographical errors in the previous version of the document, the title was amended slightly to clarify its scope. The introduction of the word 'Client' into the title recognizes explicitly the intent that DCCI be a client side interface. This also helps distinguish the specification from other standardization efforts concerned with access to delivery context from server-side environments.
A number of editorial changes were made throughout the document in order to implement this modification to the title.
This document was produced with the help of the Ubiquitous Web Application Group participants:
The editors would also like to recognize the contributions of the following members of the W3C Multimodal Interaction Group (in alphabetical order):
and the contributions of the members of the Device Independence Working Group:


text:
Taffy Town Sweat Heat Bag Chili Mango, Xtreme Hot Cinnamon & Pineapple Ghost Pepper
SKU: 074453003055 Stuckeys
For those that like it hot, Sweet Heat is the treat. A mix including chili mango, xtreme hot cinnamon, and pineapple ghost pepper, it's sure to test your tongue!
For over 100 years, Taffy Town has been manufacturing gourmet Salt Water Taffy. It is a delicious whipped taffy that melts in your mouth with a wide variety of true to life, unique, and amazing flavors. Our taffy is Made in the USA in a batch process, using the best ingredients and flavors we can find. Our factory is free of tree nuts, peanuts, and gluten. All our products contain egg whites and milk for a creamy, melt-in-your-mouth taste and texture that is without comparison. Taffy Town, Inc. is a family-owned and operated company located in the Salt Lake City area of Utah.
Each taffy piece is twisted in a wax wrapper with the trademark red Taffy Town lettering to help our ever-growing fan base identify our product wherever it may be sold. It's a colorful product with individual wrapping to make it easy to use in candy buffets, holiday treats, summer snacks, party goody bags, and more. It is a fun medium to use for creative decoration projects and crafts for both children and adults.


text:
The U.S. Federal Trade Commission has hired an outside litigator to lead its antitrust investigation of Google, a possible sign that the FTC is preparing to file a lawsuit against the search and advertising giant.
Beth Wilkinson, a partner at the law firm Paul, Weiss, will begin handling the FTC's investigation of Google on Monday.
A spokesman for the FTC said the Commission had brought in outside attorneys before, but the last time was about four years ago.
"We had a chance to get one of the best litigators in the country and we took that opportunity," the spokesman said.
The FTC began investigating Google for possible antitrust violations in the middle of last year. It's been looking at whether the search giant unfairly favors its own businesses in search results, and whether it charges higher advertising rates for competitors.
FTC Chairman Jon Leibowitz met with reporters Thursday in Washington, D.C. He emphasized that Wilkinson's hiring didn't necessarily mean the FTC was about to take Google to court, according to a New York Times report.
Google declined to comment.
Wilkinson specializes in white-collar crime. Most recently she has defended corporations, including Pfizer and Philip Morris, against government actions, but she was previously a prosecutor. Most notably, she made the closing arguments in the federal government's case against the Oklahoma City bomber Timothy McVeigh.


text:
Marketing Research
0.5 Credit
Hours per week:
- Lecture/Discussion: 3
The objective of this course is to give the student an understanding of the capabilities and limitations of market research in the context of business problem-solving. Procedures in market research are considered in some detail with emphasis on problem formulation, application of sampling methods and statistical design of experiments. The foregoing procedures are examined primarily from the standpoint of problems encountered in using statistical techniques and designing experiments suitable to the research problem.


text:
We are excited to announce a number of new policies to extend the caching and throttling capabilities of API Management.
- The cache-lookup-value and cache-store-value policies enable caching arbitrary pieces of data at arbitrary points during policy execution.
- The quota-by-key and rate-limit-by-key policies allow partitioning quota and rate limits by using custom key values. This gives developers a finer degree of control over throttling to prevent denial-of-service attacks and to enable usage based tiers for end users.
Advanced caching policies can support scenarios such as:
Advanced throttling policies support scenarios such as:
Get started
Learn how to use advanced caching and flexible throttling policies in the following guides.


text:
Central control of all the devices of a production system with Device Type Managers (DTM)
You do not need to be an expert to be able to install a printer for a PC without difficulty. Usually all that is required is to have the relevant driver installed to prepare the data for the print job, and then you can start printing.
Device Type Managers (DTM)
With Device Type Managers (DTM), this principle of operation can now also be used for the metrological monitoring of Production systems. As with printer drivers, the DTM covers all the functions required for the parameterization, operation and diagnosis of a field device, including a graphical user interface and a Help system.
Increasing the efficiency of Production systems
Integrating DTM pursues the following aims: reducing maintenance outlay and downtime, as well as improving product and production quality – the entire system can be optimized with DTM. On the one hand, demand-oriented maintenance of components is possible, so that routine maintenance activities are no longer required. On the other hand, system availability is increased, which achieves a clear increase in the efficiency of the Production systems.
Central data acquisition
To achieve these aims, data must be acquired from all the relevant parts of the system and be made available to the service engineers as easily and conveniently as possible – and this must be done at a central point of the system. Until now, the difficulty has been that the installed devices are usually heterogeneous - they come from different manufacturers, for example, and therefore also use different communication protocols. To diagnose the current status of a device, the relevant software always had to be installed, and its operation is also tied to the particular manufacturer, of course, so four devices from different manufacturers also means four different software solutions. This is exactly the problem that is solved with DTMs and the Field Device Tool (FDT) interface.
Integrating intelligent field devices into a single system
An FDT defines a unified interface that allows intelligent field devices (even from different manufacturers) to be integrated into a single system, if they have a relevant DTM at their disposal. Let us clarify this by going back to the example of a PC. For a word processing program to address a printer driver correctly, the interface between the application (the word processing program), the operating system and the driver, must be clearly defined. In an engineering system, this function is taken over by the FDT.
DTM – perfectly matched to the device
This unified interface makes it possible to integrate any devices into a system, whatever their manufacturer or fieldbus protocol. Only one relevant DTM has to be made available with the particular device. The DTM usually comes from the manufacturer and is thus perfectly matched to the device. The specific strengths and advantages of the device are retained, because it has optimum support. A particularly convenient feature is that as with PC printers, there are only marginal differences between the graphical user interfaces of all the DTMs, so that you do not first have to learn how to use it, even with a new device.
FDT frame application
Systems with an FDT interface are called FDT containers or FDT frame applications and contain the application itself – control system, monitoring, configuration, engineering or asset management. The defined FDT interface ensures interoperability. Or to put it another way, it guarantees problem-free operation of all DTMs in the required frame application.
The monitoring system example
The advantages of a system fitted with an FDT interface can easily be seen in the example of amonitoring system. Whereas previously, malfunctions had to be localized directly on the device itself, now all that is needed is to double-click the relevant DTM that has usually already sent out an alarm indication, and the service engineer is given a status report and can begin an extended diagnosis – and this can be done from a central point, from which all the parts of the system can be managed via the relevant DTM. As, for the most part, parameterization also takes place via DTM, immediate error recovery is often possible as well.
digiCLIP with DTM
HBM has developed a DTM specifically for digiCLIP industrial amplifiers, to fully exploit the aforementioned advantages. As digiCLIP also supports TEDS, the electronic data sheet in the transducer, parameterization, just like monitoring and maintenance, is child's play. Because digiCLIP detects transducers fitted with TEDS totally automatically – there is no need for complicated settings. This is Plug & Measure in the truest sense of the words.
Do you already have a digiCLIP and now want to use DTM as well? Not a problem – HBM can provide you with the appropriate Device Type Manager as a free download.
The advantages of FDT/DTM technology
- Free choice of products without any system integration restrictions
- Central access to all field devices
- Ultra user-friendly
- Supports all fieldbus protocols
- DTM management
- Unified DTM user interface
- Full support of all device functions
- The system is less complex
- Your staff need less training
- Demand-oriented maintenance
- The reduction in downtime increases efficiency and reduces cost


text:
I have no idea when – or even if – South Carolina will ever win the SEC East under Spurrier, but I've got to say with the hire of new special teams coach Ray Rychleski from Maryland, the Gamecock coaching staff may very well lead the conference in coaching quotes.
Check these out:
… "I don't care what anybody says, when anybody takes a new job, they're not taking a pay cut," Rychleski said in a phone interview.
… Maryland has not had a punt blocked during Rychleski's seven-year tenure, the longest active streak in the country.
"Let's not even talk about that. That gives me the weebie-jeebies," Rychleski said. "You don't ever want to hear the double-thump. That's the worst sound in football."
… "[Spurrier] said, 'Ray, I'd like to win a game in special teams,' " Rychleski recalled. "I said, 'Coach, first you have to make sure you don't lose a game in special teams.' "
Ah, yes, the old "double-thump". I'm not sure that's the worst sound in football, though. What the Old Ball Coach will say to the assistant he's going to can in the wake of this hire will probably sound worse.
UPDATE: Well, look what the cat drug in. Former UGA DC and current coaching nomad Brian VanGorder joins the fun and games in Columbia as the Old Ball Coach's DC. Groo's take on the hiring is spot on – I guess we'll learn how smart Pollack, Odell and Thomas Davis made BVG look.


text:
Bind As A Bat :
Black Sheep :
Someone who is the black sheep does not fit into a group or family because their behaviour or character is not good enough.
Blackball :
If you vote against allowing someone to be a member of an organization or group, you are blackballing him or her.
Blank Cheque :
If you are given a blank cheque, you are allowed to use as much money as you need for a project.
Bleeding Edge :
Similar to cutting edge, this idiom implies a technology or process that is at the forefront or beyond current practices.
Bleeding-Heart :
A bleeding heart is a person who is excessively sympathies towards other people.
Bless Your Pointy Little Head. :
This expression is used as to patronise someone especially when they do not realize that they are not very clever.
Blessing in Disguise :
A hidden favour
If some bad luck or misfortune ultimately results in something positive, it's a blessing in disguise.
Bind As A Bat :
If you are in total darkness and cannot see anything at all, you are as blind as a bat.
Blind Leading The Blind :
When the blind are leading the blind, the people in charge of something do not know anything more than the people they are in charge of, when they should have greater knowledge.
Blink of An Eye :
If something happens in the blink of an eye, it happens so fast it is almost impossible to notice it.
Blood and Thunder :
An emotional speech or performance is full of blood and thunder.
Blood Form A Turnip :
It is impossible to get something from someone if they do not have it, just as you cannot get blood from a turnip.
Bind As A Bat
to HOME PAGE


text:
For Team USA archers, every cloud truly has a silver lining. USA team members took pride in the men's team silver medal win - the United States' first Olympic medal of the London Olympic Games, and the country's first in archery since 2000 - but expressed mixed feelings about some of their other individual finishes.Khatuna Lorig (West Hollywood, Calif.), a five time Olympian and team bronze medalist, carried the hopes of her team through the quarterfinals on Thursday after becoming the first American archer to advance to the 1/8 round in these Olympic Games. Lorig opened with a shutout win versus Sherab Zam (BHU), in which she took a 6-0 victory but shot several low-scoring arrows, presumably caused by weather conditions in the stadium. In her second match, she faced a tough opponent in Louise Laursen (DEN), who took Lorig to five sets but couldn't hold off the Team USA athlete, who clinched the win with six set points.
Entering the final day of competition today, Lorig opened with a strong win in the 1/8 versus a tough opponent in China's Cheng Ming, who had posted consistent scores herself throughout the event. Keeping the majority of her arrows in the gold over five sets, Lorig was able to take a 7-3 win to advance to the quarterfinals, meeting France's Berengere Schuh.
In the quarterfinals, Lorig was most consistent in the wind, which picked up in the stadium as the match progressed. Her opponent - Berengere Schuh (FRA), an Olympic medalist and World Champion - took two set points but ultimately had too many inconsistencies in the wind to hold off Lorig, who was strong through the match with a 6-2 win, assuring Team USA another shot at a medal in the women's semifinals.
In the semifinal, Lorig met world number two ranked archer Ki Bo Bae (KOR), who delivered a tough contest for Lorig. The archers drew the first set at one all; Ki won the second set, and Lorig drew the third, but it was not enough to hold off Ki, who grabbed the victory with two more set points, giving Lorig the chance to compete for the Olympic bronze medal versus Mexico's Mariana Avitia, while Ki would face Mexico's Aida Roman for the gold medal.
In the bronze medal match, Lorig seemed affected by the wind in her first three arrows, while Avitia hit a 30 to take the first two set points. Avitia took the second set as well, but Lorig came back, bringing the match to a 2-4 deficit. Needing to win the set or tie to stay in the competition, Lorig started with a dead center ten that shattered the camera, but was unable to hold off Avitia, who took the bronze medal with a 6-2 victory, giving Lorig a fourth place finish and making her the USA's highest individual finisher for the second Olympic Games in a row.
"I had to fight with the wind over there, and unfortunately it didn't go as I expected," said Lorig with tears in her eyes as the competition finished. "I'm not a shooter who can go all the way out to the six ring [left and right]. You cannot read the wind and that's not helping. You're blocked…and you can't tell which way the wind is going. The wind was shifting left and right at my time, and I need to practice now for the next four years so I can go for 2016."
The other archers on the U.S. Olympic Team ended their London journeys with finishes in the 1/16 round and 1/32, despite their best efforts for the United States.
"I'm learning that the Olympic Games is an interesting stage that seems to have an opinion all of its own as to who should be the victor," commented Miranda Leek (Des Moines, Iowa), who was stopped in competition on Monday. The 19 year old athlete won her first match, a 6-2 victory versus Kateryna Palekha (UKR), but was unable to edge out Pia Lionetti (ITA), who won three sets and tied a third versus Leek, 7-3. "It's no joke that the Olympics is really anyone's game," she continued. "It all comes down to a handful of arrows."
Jacob Wukie (Oak Harbor, Ohio), who began his individual bid on Tuesday, said after competition that he felt he made good shots but that they didn't land as well as he expected. Wukie won his first contest, stopping India's Jayanta Talukdar with a 6-0 shutout victory and just three arrows out of the ten ring. In his second match, however, it was Baard Nesteng of Norway who took the win, shooting six set points to Wukie's two. "I gave it my best and was happy with how I was able to shoot," wukie said in a post to fans. "It was truly a blessing to be on this team, to compete at this level and to be coming home with a medal."
Three-time Olympian Jennifer Nichols (Cheyenne, Wyo.) approached her finish with the same positive attitude that her teammates expressed. Nichols, who pulled off a 6-5 finish versus Chekrovolu Swuro (IND), moved on to face Mongolia's Bishindee Uratungalag, who took the win over Nichols, who retired after a 4-6 loss. "It's archery…it's a season of life," Nichols said in interviews after her match. When asked about her future plans, Nichols - who is engaged to be married in September - put archery in perspective, saying it is a part of her life that will be more focused on family going forward.
Brady Ellison (Payson, Ariz.), the world's number one ranked archer who was widely considered a medal contender, gave the packed house at Lord's Cricket Ground one of its biggest surprises of the week, not with his win in the 1/32 round, but with a stunning loss in the 1/16. Ellison started the day strong, clinching a 7-1 win versus Mark Javier (PHI), shooting just two arrows out of the gold over four sets despite a swirling wind.
That wind, however, proved the determining factor in Ellison's heartbreaker of a loss to Australia's Taylor Worth in the 1/16. Worth, who previously stopped Ellison at the third stage of the Ogden World Cup earlier this year, seemed determined to have a replay of that match, and succeeded by the same margin that Ellison defeated Javier. "It just sucks," said a disappointed Ellison as he exited the field of play. "I had several shots that I thought were good that didn't hit…I mean dumbfounded. It was either me or Taylor guessed the wind a lot better than I did. The wind that you feel on you is the complete opposite of the flags." When asked what was next for the two-time Olympian, Ellison said simply: "get ready for Rio."
Jake Kaminski (Elma, New York), Ellison's teammate, had a similar experience with the wind that resulted in an even earlier elimination from individual match play, with a shocking loss to 15 year old Dan Olaru of Moldova, the youngest archer on the field. Kaminski amassed a commanding lead, taking the match to 5-1, but with a six and a four from Kaminski, Olaru managed to tie the match and force a shoot-off, in which Kaminski shot a seven that ended his bid here in London.
"Really tough out there with the wind, there's absolutely no way to read the wind at all," lamented Kaminski in a post-competition interview. "It's very very difficult to go out there and show what we can do because of the conditions. It's tough." When asked what his immediate plans were, Kaminski noted that he was looking forward to seeing more of London and other events: "I'm going to continue to absorb the Olympics," he explained.


text:
It's officially Dead Week: the week before finals that seems so busy, insane and hectic that this one week feels like ten! But I'm not even stressed, because I've found the perfect stress relief method for me. On Sunday nights at 10 P.M., a few of my friends and I go to mass at Memorial Church (we call it MemChu), and it's SO refreshing to sit in such a beautiful place when it's dark out and everything is quiet, and you can just sit and reflect on the past week (and the upcoming week). When I leave, I always get a feeling that's really similar to how I feel after a great yoga session – I'm
totally relaxed, but super energized at the same time! I'm SO fortunate that I have such a beautiful place to start my week each Sunday. Seriously, how pretty is this church!? Imagine it at night, lit up with a bunch of stars above it in the sky – beautiful.
That's my favorite way of relieving stress, and I definitely recommend that each of you finds your own perfect stress relief location when you get to college. Already found yours? Let me know about it in the comments!
Have a great week everyone!
More From Seventeen


text:
This review project will continue throughout the life of the LDP. The process will act as a front-end quality assurance review for new documentation which is submitted to the LDP. Ideally documents will be reviewed within one week of their submission to the LDP.
Coordinators of this effort will announce to the list or notify individual review members of new document submissions. The coordinators will try to funnel documents to reviewers who have knowledge in the same technical area as the documentation. If the reviewer is not a technical expert in that particular area and needs technical questions answered, there will be a technical expert designated who will be able to address any technical issues or questions.
Once reviewers have agreed to work on a document, they will have one week to complete the review. If they are not able to complete the review within that time frame, they will need to let the coordinator know of their difficulties so that the author can be notified of the problem. Because these reviews need to be conducted quickly, there will be times when reviewers will be more able to accept review work.
When reviewing newly submitted documents, refer to the Section 5 and Section 6 portions of this guide for the types of information to verify and correct. As a reviewer, you will need to check the documents out of the CVS [1] and make any necessary changes. If changes are extensive or if the document has glaringly and fundamentally fatal errors, contact a coordinator and let them know what the problems are. Once changes are made, the reviewer will update the minor version number, add a new entry to the revision history, and include their name as an "editor" of the document. These changes will then be submitted to the CVS, and an original copy will be sent to the author of the document if the author does not have CVS access.
Alternatively, if you've obtained the file from the Review Coordinator, or are unfamiliar with CVS, you can return the changes to the coordinator for further handling.


text:
A couple of folks have expressed an interest in joining our weekly Chades (CHAracter DESign) Challenges, so I'll be posting the weekly subject on this here blog for everyone to see. Two different sketcheteers will be choosing the words (a noun and adjective) on a friday, and we'll have a week to do as many drawings on the subject as possible. On the following friday, we'll all post our art on our own blogs, this way people will go to eachother's blogs more often to check out what's new, promoting community and all that jazz. I'll post a list of people who participate each week so you know where to hunt for inspiration. After we've all seen eachother's drawings of glory (and allotted the appropriate compliments and reprimands), we will have one more week on that same subject too push it and 'borrow' eachother's designs to explore them as thoroughly as possible. On the following friday, we'll post the final drawings on the subject, and two new artists will elect a new theme. Capiche?
Check in tomorrow for 'Deformed Sorcerers' from


text:
Pop in for a warm welcome from karen and her lovely team at the Stroud store! New arrivals are landing every week across all departments; womens clothing, mens clothing, kids clothing, teen clothing and homeware. Whether you're browsing our everyday styles, shopping for an occasion or just collecting an order - our team are on hand to help you. We'll see you soon.
Our journey to becoming a more sustainable M&Co.Find Out More
We know a thing or two about loyalty - that's why we've created a loyalty scheme to give back to you, our valued customers. Sign up today and we'll treat you to exclusive benefits!Sign Me Up


text:
Private police: One of 19 provides records
Here's a footnote to today's story on how the records of private police agencies are shielded from the public.
On Dec. 23, The Dispatch sent emails to the police departments and public-relations officials with 16 private universities and three Columbus-area hospital systems asking for copies of arrest reports from 2013.
The private-sector police largely replied since they are privately operated -- and not funded or overseen by government -- they are not required to turn over records under Ohio's public records laws.
Capital, Dayton, Denison, Muskingum, Otterbein, Wittenberg and Xavier universities, as well as Marietta College, declined to provide records.
Ohio Wesleyan University said its lone certified officer made no arrests last year. Walsh University provided the names of those who their officers arrested, but turned over no records. While saying it was not required to do so, the University of Rio Grande provided records, but redacted or blacked out all students' names.
Case Western, John Carroll and Wilberforce universities, the College of Mount St. Joseph and Notre Dame College did not respond to the requests for records.
Among area hospitals, Licking Memorial in Newark turned over complete, detailed records of its officers' arrests. OhioHealth, which operates Grant and Riverside Methodist, said it is not subject to public records laws. OhioHealth reported its officers make no arrests, but detain suspects for arrest by Columbus police. Fairfield Medical Center in Lancaster said it kept no arrest records, but that information on its officers' arrests could be found in court records.


text:
17 March 2010
Custom 1/144 Rebornnu Gundam
Spotted this custom "Rebornnu Gundam" over at Hobby no Toriko (which means "slave of hobby"), of which the base model is the HG 1/144 Reborns Gundam (from Gundam 00) modded to look like the famous Nu Gundam from Char's Counterattack. Hence the name "Rebornnu Gundam".
Colour scheme is changed to white and black instead of white and red, with a bit of red and yellow on smaller details. The backpack is changed completely so that the gimmick to transform to Reborns Cannon is removed, and instead the Fin Fangs are now mounted in the way like the Nu Gundam does. The mouting packpack somehow does remind me of Destiny Gundam's from Gundam SEED Destiny.
In case people do not know how the original Gundams should look like:
Reborns Gundam
Nu Gundam
One interesting thing to note is that both pilots of Reborns Gundam and Nu Gundam are voiced by the same voice actor or seiyuu - Toru Furuya
Various action poses of the Rebornnu Gundam. Fin Fangs / Fin Funnels can be seperated from mounted positions.
Wow, it actually looks much cooler than the original in my opinion! It may be how the Nu Gundam is a very solid design in the first place, making the converted Rebornnu Gundam looking more attractive now than the original Reborns Gundam, in Gundam 00 style mecha design~
Reborns Gundam, which debuted in penultimate episode of Gundam 00 Second Season, could transform an alternate mode called Reborns Cannon via a back-to-back transformation, which I am not too fond of. It is quite an unusual design and perhaps unique too, but I do prefer the two forms to be seperated into two different MS (like the prototypes 1 Gundam and GN Cannon). Now that HG 1/144 1 Gundam gunpla is announced for May release, I may consider buying one over Reborns Gundam. An unexpected release but I welcome it~
All Rebornu Gundam images from Hobby no Toriko
Reborns Gundam and Nu Gundam images from Dalong
13 comments:
This is epic! @.@ReplyDelete
it going to release one gundam?.. where you spotted from?.. is it from the one of the magazine you show us in previous post?.. wow.. that will be great..ReplyDelete
Wow, F-wker, I hated reborns with a passion, but this, this is freaking Awesome!!ReplyDelete
- Anonymous18 March 2010 at 22:55
I love it when 2 ideas/kits merge together! WIN! ^_^ReplyDelete
@ AstrayP03 (Zhe):ReplyDelete
Definitely more epic than the original Reborns Gundam IMHO!
@ seven6398:
HG 1/144 1 Gundam (pronounced "Ai Gundam" as in the alphabet "I") is announced in Hobby Japan April issue. There's no picture of it, but the annoucement can be seen in one of the scans (in NK or SRW Hotnews). Price will be 1890 Yen including tax.
@ GunStray:
Reborns is a bit of a strange Gundam in terms of the transformation gimmick, but without it and now looking more like a Nu it definitely looks cooler I think!
@ robostrike:
Hybrids are always fun (reminds me of Acguy Freedom all of a sudden lol), and are definitely win when they work well! This one is definitely one of them!
RX-78 = o gundam
nu gundam = rebons
nice idea =D
O_o very cool! I agree that it is much nicer than the original Reborn Gundam. Anyone want to make their Exia into RX-78-2 colour scheme?ReplyDelete
@ moemoekyun:ReplyDelete
IF Ribbon's boss-like mech at final episode were to be a revamped Nu Gundam it would be quite interesting like Amuro Ray's final Gundam, and it would be even more of an interesting shift seeing him and Setsuna later downgrading back to their first Gundams for the ultimate showdown (O Gundam vs Exia R2).
@ B-Mecha:
Indeed! I am liking this Rebornnu more and more! As for Exia, I think Astraea will be a slightly more fitting one to choose for the RX-78-2 colour scheme due to its armament. I have yet to see one coloured that way though.
- Anonymous26 March 2010 at 17:34
Dayyum~! Makes me want to get Reborns... or I-Gundam... >_<ReplyDelete
@ bd77:ReplyDelete
I do plan to get 1 Gundam (the gunpla kit now called 1 Gundam Kai with wing-like binders); definitely prefer that over Reborns!
Does this needs some extra parts to rearrange the fin fangs like that??ReplyDeleteReplies


text:
They call the place happy valley, though it has not been so much that this year. As I drove over the hills my mind drifted to my Alma Mater's book store which sells T-Shirts that read "Not Penn State"; then I saw this.
Then right after that I saw this.
That explains everything. Maybe the football program is divinely inspired (the sport itself is in fact divinely inspired. There is no room for argument on this) and should be protected at all costs? yeah, no.
The sadness in the whole series of events is that Penn State is first rate in so many other things. Granted the campus did not awe me, I have no deep love for gargantuan straight lined building that scream 1972.
But if you are a scientist or educator, or aspire to be one.. or aspire to being so many other things, it is by all accounts a top shelf school.
But sadly, over the past decade or so, if you happened to be an underprivileged young boy, the school was willing to sacrifice your youth and peace of mind to protect a revenue stream.