Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark,document use and software licensing rules apply.
This document describes an Abstract Model of XML Protocol.
The challenge of crafting a protocol specification is to create a description of behaviour that is not tied to any particular approach to implementation. There is a need to abstract away from some of the messy implementation details of buffer management, data representation and specific APIs. However, in order to describe the behaviour of a protocol one has to establish a set of (useful) concepts that can be used in that description. An abstract model is one way to establish a consistent set of concepts. An abstract model is a tool for the description of complex behaviour — it is not a template for an implementation... although it should not stray so far away from reality that it is impossible to recognise how the required behaviours would be implemented.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This W3C Working Draft (WD) of the XML Protocol Abstract Model has been produced by the XML Protocol Working Group (WG), which is part of the Web Services Activity.
The WG has decided to discontinue work on the Abstract Model, and on this document. The WG developed the Abstract Model to provide a framework for evaluating candidate protocols and for reasoning about the development of the protocol itself. The WG believes the Abstract Model has well served its purpose in this regard, and it no longer intends to do any further work on the model.
This document represents the contents of the first Abstract Model WD (http://www.w3.org/TR/2001/WD-xmlp-am-20010709/) plus some small changes. This document contains various open questions, however the WG does not intend to answer them directly although answers may be found in other documents produced by the WG.
This document uses the term "XML Protocol", or the short form "XMLP", to refer to the protocol being modelled.
Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.
The WG has decided to discontinue work on this document and feedback can be sent to<EMAIL_ADDRESS>(archived public list); however, the WG does not intend to respond to such feedback.
This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of all W3C technical reports can be found at http://www.w3.org/TR/.
1 Introduction
1.1 Definition of Terms
2 XML Protocol Abstract Model Overview
3 XML Protocol Layer Service Definition
3.1 XMLP_UnitData Operation
3.1.1 Correlation at Sending and Receiving XML Protocol Applications
3.1.2 XMLP_UnitData Operation through Intermediaries
3.1.3 Message Correlation at Intermediary XML Protocol Applications
3.2 Operation Parameters
4 XML Protocol Applications and Modules
4.1 XML Protocol Message Routing and Targeting (aka Naming and Addressing :-))
4.2 XML Protocol Modules and Message Processing
5 Underlying Protocol Bindings
5.1 Binding Service Model
5.1.1 Introduction
5.1.2 Service Primitives
<IP_ADDRESS> Message Exchange
<IP_ADDRESS> Message Correlation
<IP_ADDRESS> Errors
5.1.3 Message Exchange Patterns
<IP_ADDRESS> One Way Message
<IP_ADDRESS> Request Response
<IP_ADDRESS> Request and n Responses
5.1.4 Sample Mappings
<IP_ADDRESS> HTTP
<IP_ADDRESS> SMTP
5.1.5 Binding Considerations
5.2 BindingContext
5.3 Attachment of Arbitrary Content
6 References
7 Acknowledgements
An abstract model is a useful means to develop a description of a system. It abstracts away from practical details such as specific API definitions, data representation, and buffer management. It provides a way to give a precise description of the externally visible behaviour without being prescriptive of implementation architecture.
This document is intended to serve as an overview and introduction to the XML Protocol and its framework.
2 XML Protocol Abstract Model Overview presents an overview of the abstract model
3 XML Protocol Layer Service Definition presents a model for the services provided by the XML protocol layer to XML protocol applications.
4 XML Protocol Applications and Modules presents a model for the extensible processing of XML protocol messages.
5 Underlying Protocol Bindings presents a model for the binding of XML protocol to underlying protocol layers.
This document makes use of terms defined in the [XMLPReqs]. Additional terms introduced in this document are defined locally in this section, however, in the long term we anticipate that they will be incorporated into a single glossary for all documents produced by the WG.
| XMLP Application |
A client or user of the services provided by the XML Protocol Layer. An XML Protocol Application may act in the initiating or responding role with respect to two-way request response operations and in the sending or receiving roles with respect to one-way operations. XML Protocol Applications may also act in an intermediary role with respect to both two-way and one-way operations. XML Protocol Handlers are encapsulated within XML Protocol Applications. |
| XMLP Layer |
The XML Protocol Layer is an abstraction that provides services or operations that transfers packages of XML Protocol Blocks between peer XML Protocol Applications via zero or more XML Protocol Intermediaries. |
| XMLP Operation |
A primitive capability or service offered by the XML Protocol Layer. The XML Protocol Layer supports 3 operations described in detail in 3 XML Protocol Layer Service Definition. XMLP Operations are modelled as sequences of events crossing the layer boundary between XML Protocol Processors and XML Protocol Applications. |
Figure 2.1 below presents a simple case of the XML Protocol abstract model. Hosts I and V each contain XML protocol application components, which use the services of the XML protocol layer, and XML protocol layer components which provide the services of the XML protocol layer. The services of the XML protocol layer are abstracted at the upper layer boundary as a single operation, XMLP_UNITDATA which is described in detail in 3 XML Protocol Layer Service Definition.
Figure 2.2 below shows 5 hosts in a more complex case of the XML Protocol abstract model. Hosts I, III and V each contain XML protocol application components. Hosts II and IV are intermediaries that operate within underlying protocol layers such as HTTP proxies and SMTP message routers.
Figure 2.2 can be used to discuss a number of message exchange scenarios. For example, the XML protocol Processor at Host III is bound to two, possibly different, underlying protocols. It could serve merely as a 'helper' to transition an XML protocol message from one underlying protocol to another in circumstances where the initiating processor is bound to a different underlying protocol infrastructure than the receiving or responding node, say Host V in figure 2.2. A similar scenario arises if Host III is part of an XML Protocol Firewall that controls the ingress and egress of messages from a given organisation. In both these circumstances the XML Protocol Handler(s) within the XML protocol application at Host III need not be present.
If we turn our attention to the operation of the XML protocol applications above the XML protocol layer boundary, we have a scenario in which the application at Host I has some XML protocol blocks to deliver to Host V. In addition the application at Host I needs to trigger Intermediary functionality at Host III by the inclusion of several XML Protocol Blocks. "XML Protocol Block 1" is intended for "XML protocol handler (e) " within the application on Host V. Block 2 is intended for handler (h) and handler (c) which replaces Block 2 with Block 3. Also, the XML protocol application at Host III inserts Block 4 into the message forwarded from Host III to Host V. Blocks 3 and 4 are intended for handlers (f) and (g).
This section focuses on the definition of an abstract interface between the XML protocol applications and the XML protocol layer. It needs to be remembered that the layer interface described in this section is abstract - its purpose is to enable description, not to constrain implementation.
The services provided by the XML protocol layer are modeled a single operation. XMLP_UNITDATA provides services to sending, intermediary and receiving XML protocol applications.
XMLP_UnitData is a best effort one-way message transfer operation with message correlation. Multiple message transfer operations can be correlated in various ways to form message exchange patterns like request/response, and long-lived dialogs.
The XMLP_UnitData operation is modeled by four primitives (events). Each primitive models a transmission, reception or status event at interface between an XML protocol application and an XML protocol processor:
XMLP_UnitData.send( To, [ImmediateDestination], Message, [Correlation], [BindingContext]);
XMLP_UnitData.receive( [To], [From], Message, [Correlation], [BindingContext]);
XMLP_UnitData.status( [From], Status, [BindingContext]);
XMLP_UnitData.forward( [ImmediateDestination], Message, [BindingContext]);
All parameters are detailed in
3.2 Operation Parameters.
Conceptually the XMLP_UnitData operation encapsulates the transmission of an XML protocol message from a sending XML protocol application to a receiving XML protocol application. The principal conceptual difference between sending and forwarding an XML protocol message is that, from a message correlation point of view, sending generates a new message whereas forwarding passes on an existing message. Conceptually the forwarded message is the same message as previously received although the action of intermediary processing may have changed the value of the message.
Figure 3.1 below illustrates the normal use of these primitive at the sending and receiving XML protocol applications.
The operation is best effort which means that it can fail silently with the loss of the message in transit. A lost message may have been partially processed at an intermediary XML protocol application. The success or failure of the operation is reported via the XMLP_UnitData.status primitive. In some circumstances it may only be possible to report that a message has been sent. In other circumstances it may be possible to report that a message has or has not been delivered to its ultimate recipient.
XMLP_UnitData.send is invoked by the sending XML protocol application and directed at the local sending XML protocol processor to start a one-way transfer operation.
Upon receipt of this primitive by the sending XML protocol processor an XML protocol message is transferred from the sending XML protocol processor toward the receiving XML protocol processor (possibly via intermediary XML protocol processors).
This primitive differs from the .forward primitive in that it is used by the initial sender of an XML protocol message to send a new message.
XMLP_UnitData.receive is invoked by the receiving XML protocol processor and directed at a local receiving XML protocol application to deliver a received XML protocol message.
This primitive is invoked as a result of the arrival of an XML protocol message from the sending XML protocol processor (via the underlying protocol layers).
XMLP_UnitData.status is used to report on the delivery status of the operation to the sending XML protocol application. This primitive may be used to report to the sending XML protocol application on the success or failure to send and deliver a message to the receiving XML protocol application. In general, it is not possible to assert that a message has been delivered to the receiving XML protocol application without engaging in further interactions. With care it is possible to assert definite failure to deliver provided that circumstances are such that there is no possibility of subsequent delivery. From the point-of-view of the initiating XML application the operation has completed once this primitive has been invoked.
XMLP_UnitData.forward is invoked by an intermediary XML protocol application once it has completed intermediary processing of a message in transit and directed at the local intermediary XML protocol processor.
In the event of success the message is forwarded to its next destination, as designated by the ImmediateDestination parameter if given. Alternatively an implementation or configuration dependent method may be used to select the next recipient of the message along a path.
In the event of failure, the message in transit is discarded. A correlated fault message may be generated by the intermediary XML protocol application and sent toward the originator of the failed message.
This primitive differs from the .send primitive in that it is used by an intermediary XML protocol application to forward an existing XML protocol message received by the intermediary XML protocol application.
An XML protocol application may engage in multiple concurrent operations with the same or different intermediary and/or receiving XML protocol applications. These concurrent operations are independent and the order in which they are processed by the receiving and intermediary applications may be different from the order in which they are invoked or complete at the sending XML protocol application.
The Correlation parameter provides a general mechanism by which richer message exchange patterns such as request-response and request/multi-response can be derived on top of the one-way message exchange pattern of the XMLP_UnitData operation. The mechanism by which correlation is determined is not specified in this abstract model.
Message correlation may be determined through:
the exploitation of features in the underlying protocol eg. the request/response nature of HTTP;
mechanism introduced either by the XMLP processor to operate across multiple possible underlying protocols.
mechanism introduced by a binding to a particular underlying protocol within the domain of the underlying protocols own header extension mechanism.
When included in an XMLP_UnitData.send primitive Correlation.MessageRef indicates that the XML protocol message being sent is a direct consequence of the processing of an XML protocol message previously received by the sending XML protocol application and referenced locally by Correlation.MessageRef.
Likewise, when included in an XMLP_UnitData.receive primitive Correlation.MessageRef indicates that the message being received is a direct consequence of the processing of a XML protocol message previously sent by the receiving XML protocol application and referenced locally by Correlation.MessageRef.
Failures that arise during message processing at the recipient or at intermediary XML protocol applications may result in the generation of fault messages directed toward the originator of the message whose processing gave rise to the fault. Such fault messages are a direct consequence of the faulted message and this should be indicated through the use of the Correlation parameter.
Conceptually an XML protocol intermediary does not generate a new XML protocol message, it operates on an XML protocol message in transit. Thus the received message and the forwarded message are regarded as the same message although the intermediary may change the value of the message.
Figure 3.2 shows the normal behaviour of an XML_UnitData operation through an intermediary in the absence of fatal failures. The three vertical lines represent the local XML protocol layer boundaries and the small arrows above denote the up/down orientation of the boundary. Figure 3.3 below shows an alternate representation of the same scenario.
The scenario depicted in figures 3.2and 3.3. show just a single intermediary interposed in the operation however the principle extends to an arbitrary number of intermediaries.
It is worth noting that the XMLP_UnitData.status is generated from within the XML protocol layer. It may indicate anything from the mere fact that the message has been sent or forwarded by the sending node; that its has been received and/or sent from the intermediary node; or that it has indeed been delivered to the ultimate recipient node. What it means in a given circumstance will depend upon the capabilities of the underlying communications protocols used to construct the message path. The strongest thing that it can indicate is the failure to deliver an XML protocol message to its ultimate recipient.
The Correlation.MessageRef sub-field of the optional Correlation parameter on a XMLP_UnitData.receive primitive carries a local abstract reference to an XML protocol message that was previously forwarded by this intermediary XML protocol application. The current message is a direct consequence of the processing of that earlier forwarded message.
Typically this will arise when an application level response travels along a path that passes through one or more of the same intermediary XML protocol applications that the corresponding request passed through earlier.
This section describes the operation parameters used in the operation primitives described above.
| To |
An abstract reference that denotes the XML protocol application that a message was originally sent to by the initiating or sending XML protocol application. |
| From |
An abstract reference denotes the sending XML protocol application in .receive primitives. In .receive primitives this parameter makes the identity of the sending/initiating XML protocol application available to the receiving/responding XML protocol application. Editorial note [Intermediaries may obscure this or we may require that they don't... discuss!]In the XMLP_UnitData.status primitive, this parameter conveys the identity of the XML protocol application to which an XML protocol message was sent after any redirections imposed by underlying protocols. NB. Further redirections may occur that cannot be reported. Editorial note [Again possibly obscured by intermediaries...] |
| ImmediateDestination |
An identifier that denotes the immediate destination of an XML protocol message. If this parameter is unspecified, the default value is implementation and configuration dependent. This parameter enables sending and intermediary XML protocol applications to address the message to the next intermediary on route. |
| Message |
An abstraction of an XML protocol message exchanged between sending and receiving XML protocol applications. An XML protocol message has the following sub-fields: Message.Faults; Message.Blocks; and Message.Attachments. |
| Message.Faults |
An abstraction of a collection of XML protocol faults carried in an XML protocol message that is correlated with the XML protocol message whose processing gave rise to one or more faults. Such a message may arise at an intermediary or at the ultimate recipient. |
| Message.Blocks |
An abstraction of the XML protocol blocks within an XML protocol message which are intended to be processed by intermediaries or the ultimate recipient. |
| Message.Attachments |
An abstraction of the a collection of arbitrary attachments being transferred as part of an XML protocol message. These attachments are opaque bytes as far as XML protocol processing elements are concerned. From the point-of-view of abstract service definition the actual mechanism used to transfer attachments is immaterial, however particular bindings may employ more efficient mechanisms than others. Editorial note [NB. This places an obligation on XML protocol binding specifications to specify how attachments are to be carried.] |
| Correlation |
An optional parameter used to express local relationships between XML protocol messages. At present only a single subfield, Correlation.MessageRef is defined, however it is conceivable that other subfields may be defined in future, eg. Correlation.MsgSequence to distinguish between and potentially order n multiple messages that arise from the same source as a direct consequence of the current message. |
| Correlation.MessageRef |
An abstraction of a local reference to the local abstraction of an XML protocol message the processing of which the current XML protocol message is a direct consequence. In XMLP_UnitData.send primitives, the value of this parameter references an XML protocol message previously received by the sending XML protocol application. In XMLP_UnitData.receive primitives, the value of this parameter references an XML protocol message previously sent or forwarded by the receiving application. |
| BindingContext |
This parameter references an abstract structure that carries information pertinent to the underlying protocol binding(s). For example it may carry certificates, ids and passwords to be used by the sending/initiating XML protocol application to authenticate itself and/or to establish a secure channel. At the responding XML protocol application it may carry the authenticated id of the principal on whose behalf the operation is being conducted. If the information present in the BindingContext is inadequate for the execution of a given service primitive the invocation of that primitive will fail with a result that indicates why progress was not possible. BindingContext is optional and if not supplied the local default binding will be used. In the case of multiple bindings being available, inbound BindingContext indicates how an inbound message was received and outbound BindingContext constrains the choice of binding used for a given operation. BindingContext is discussed further in 5.2 BindingContext. Editorial note [NB This concept places another obligation on XML protocol binding specifications in that they must enumerate what binding specific information they require in an outbound BindingContext and what binding specific information they provide in inbound BindingContexts.] |
| Status |
In .status primitives this parameter indicates the disposition of the request operation which may be: MessageSent, MessageDelivered, Unknown and FailedAtIntermediary. The interpretation of a status value may be augmented by information carried in the BindingContext. |
An XML protocol application is the logic at an XML processor that makes use of the core messaging services of the XML protocol. XML protocol applications may initiate, respond or act as intermediaries in XML protocol operations. Logically, an XML protocol application contains a number of XML protocol handlers that are responsible for applying the processing rules associated with XML protocol modules. The unit of exchange between XML protocol handlers are XML protocol blocks.
XML protocol blocks are aggregated into XML protocol messages and may be targeted at particular XML processors (see 4.2 XML Protocol Modules and Message Processing). XML protocol blocks are delivered together with the rest of the XML protocol message which encapsulates them (and its attachments if any) to the targeted XML processor. The XML protocol application is then responsible for identifying and dispatching the appropriate XML protocol handlers. Generally, the dispatch to a handler will be determined by the presence of an associated block or blocks, but not necessarily. Handler d in Figure 2.2 illustrates such a case.
Each handler may succeed or fail fatally. It is the responsibility of the XML protocol application to determine the overall result of the actions of any XML protocol handlers it invokes and to augment any Faults structure carried in the ongoing message. In cases where there are multiple influences on the ImmediateDestination, it is also the responsibility of the XML protocol application to resolve any conflicts.
An XML protocol message path can be viewed as the sequence of handlers that an XML protocol message passes through between initiating/sending XML protocol application and receiving responding XML protocol application. With reference to figure 2.2, the diagram in figure 4.2 depicts the message path of the corresponding XML protocol message under the XML_UnitData operation.
The path in figure 4.2 shows sequential handler processing at the sending node, Node I, while the handler processing at Nodes III and V is concurrent (at least logically). Combinations of handlers that can be invoked concurrently from within an XML protocol application are said to be mutually orthogonal.
XML protocol modules are the unit of extension within the XML protocol. An XML protocol module encapsulates the syntactic constructs of an extension, known as XML protocol blocks, and the behavioural rules associated with the generation and processing of an XML protocol block. The abstraction for the processing and/or logic defined by an XML protocol module is called an XML protocol handler.
The SOAP 1.1 specification (section 2) states: "Processing a message or a part of a message requires that the SOAP processor understands, among other things, the exchange pattern being used (one way, request-response, multicast, etc.), the role of the recipient in that pattern, the employment (if any) of RPC mechanisms such as the one documented in section 7, the representation or encoding of data, as well as other semantics necessary for correct processing." An XML protocol module is the locus for understanding blocks associated with that module. A given message may employ the services of many modules, both generic (e.g., security, caching, compression, transactions, etc.) and application-specific.
The following list provides an initial set of concepts which capture and slightly refine the SOAP message processing model. A comparison of each concept with SOAP is also provided for reference.
An XML Protocol message consists of a set of zero or more blocks.
Editorial note SOAP: Similar. Blocks correspond to header or body entries. SOAP groups header entries into an optional Header element and body entries into an obligatory Body element.Each block has the following sub-fields: Block.Id, Block.Actor, and Block.MustUnderstand. Block.Id is an optional identifier that identifies the block for the purposes of reference by other blocks. Block.Actor identifies the XMLP processor that is intended to process the block. Block.MustUnderstand specifies whether the intended semantics of the block must be carried out.
Editorial note SOAP: SOAP does not specify whether an actor URI is to be interpreted extensionally (naming a particular node) or intensionally (describing a node or group of nodes that satisfy some property). Special reserved URI's describe nodes which are encountered next or last. Beyond the reserved URI's, there is no particular semantics associated with an actor URI. Semantically, the URI's can signify a processor that supports a given application, module or capability, or it can describe a destination, node or location. This flexibility is preserved in XMLP.The fully qualified name of the top element of a block identifies the block.
Editorial note SOAP: SOAP identifies blocks by the fully qualified element name. The block can (but need not) be mapped to some appropriate handler. Other schemes have also been suggested. For example, an attribute could name a module which would take responsibility for selecting the handler to invoke.The following values for Block.Actor
have special significance: Next
, Final
, and
None
.; Next matches the next processor. Final
matches the final processor. None is for untargeted blocks
which may be referenced by other blocks.
An empty actor defaults to Final. An untargeted block
marked with None
is useful for
declarative information that is referenced by another block or
blocks. It is guaranteed not to be removed and can even be
referenced by blocks which are targeted at different
processors.
Final
designates. The intended (final) processor must
recognize itself as such. Next
has the same interpretation as
the SOAP URI, http://schemas.xmlsoap.org/soap/actor/next
SOAP
forces the actor for body entries to be the final processor.
SOAP permits the inclusion of blocks for which there do not turn
out to be any actors that match along the message path; and even if
an actor URI matches a given processor, the processor may determine
that no behaviour is associated with the block. The value
None, on the other hand, is a stronger statement on the part of the
sender that signifies that no processor will qualify as a matching
actor.
When a block is selected for processing at an intermediary, the block is removed from the envelope. A handler may add zero or more blocks. Blocks which are merely referenced are not removed.
Editorial note SOAP: SOAP doesn't allow body entries to be processed at intermediaries and hence they are never removed at an intermediary.The XML Protocol blocks are ordered
within the envelope. This order is followed by each processor
as it selects and processes blocks, yielding a limited facility for
specifying sequential constraints. Two alternatives are
available for more complex orderings and constraints.
Hierarchical constraints can be achieved by syntactically scoping
blocks inside one another. Finally, blocks can be
incorporated by reference using the "id
" and "href
" attribute mechanism.; Using these techniques, more elaborate "manifest" blocks which direct the
processing of other blocks can be designed. From the processor's point of view, only the outermost element of the block is seen.
The processing of a block by a handler may result in a fault or a successful evaluation. A fault terminates processing of the block and message and causes a return message containing the fault to be generated if a return path is available. Rather than fatally faulting, it is also possible for a handler to insert a block targeted to another destination e.g., the final destination). This block can contain status information, non-fatal errors, or other results that can be further processed, incorporated into a return value, etc.
Editorial note SOAP: Similar.It is the intent that the XML protocol be capable of being bound to a variety of underlying communication protocols. The XML protocol working group will define a binding to HTTP. It is anticipated that others will create bindings to SMTP, TCP, SSL, BEEP and others.
This section presents an abstract service model that XML protocol bindings will supply to the upper XML protocol layer. The intent is to describe the interactions between the XML protocol processor and underlying protocol bindings and to demonstrate how these interactions are choreographed to enable multiple message exchange patterns. This model is intended to provide a framework in which the development of concrete binding specifications can be discussed. This is not intended as an API specification.
The diagram below shows a logical layered view of the binding model with the XML protocol processor being bound to four underlying transports.
This document concerns itself with the interactions at the solid black line between the XML protocol processor and a given binding.
Note that, as shown, some bindings may be nested. e.g. a MIME binding might be nested within a HTTP binding to allow additional binary data to be sent along with (but outside) the XMLP envelope.
There are two primitives associated with message exchange: MSG.req
and
MSG.ind
. A MSG.req
primitive
is sent from the XML protocol processor to the binding in order to
cause the binding to send a message. A
MSG.ind
primitive is sent from the binding to the XML
protocol processor to indicate arrival of a message.
In order to support message exchange patterns that are more complex than the simplest one-way exchange, some form of message correlation is required. For example, in a request-response message exchange there must be some means of correlating the request with the response. In this document a single instance of a message exchange pattern is referred to as an XML protocol processor operation or just operation for short.
There are four pairs of primitives associated with operation delineation and hence message correlation:
OP.start-req
and OP.start-conf
A OP.start-req
primitive is sent
from the XML protocol processor to the binding to request
initialisation of a new correlated message exchange. The binding
responds with a OP.start-conf
primitive.
OP.start-ind
and OP.start-resp
A OP.start-ind
primitive is sent
from the binding to the XMPL layer to indicate that a new
correlated message exchange is being requested. The XML protocol
processor responds with a
OP.start-resp
primitive.
OP.end-req
and OP.end-conf
An OP.end-req
primitive is sent
from the XML protocol processor to the binding to terminate a
correlated message exchange. The binding responds with an OP.end-conf
primitive. Whilst the OP.end-conf
is outstanding, the XML
protocol processor must be prepared to continue to receive MSG.ind
s
OP.end-ind
and OP.end-resp
An OP.end-ind
primitive is sent
from the binding to the XML protocol processor to indicate that a
correlated message exchange is to be terminated. No further MSG.ind
will be delivered as part of the
corresponding operation, however the XML protocol processor
receiving the OP.end-ind
primitive
may continue to issue MSG.req
primitives to complete operation in progress. Once all MSG.req
primitives associate with the
operation have been issued the XML protocol processor concludes the
operation by with the invocation of an
OP.end-resp
primitive."
The actual correlation mechanism is underlying protocol and
implementation specific. e.g. A
OP.start-conf
may carry some unique identifier that must be
provided with any subsequent
MSG.req
(s) and is included with any subsequent MSG.ind
(s).
There is no retained state within the binding between operations although there may be during operations.
The following sections illustrate the choreography of XML protocol binding primitives for a number of different message exchange patterns. These are intended to be illustrative rather than proscriptive. In particular, in many cases either sender or receiver might initiate the OP.end-req.
Sender
OP.start-req
, OP.start-conf
,
MSG.req
, OP.end-req
, OP.end-conf
.
Receiver
OP.start-ind
, OP.start-resp
,
MSG.ind
, OP.end-ind
, OP.end-resp
.
Comments
Note that depending on the underlying protocol the primitives at
sender and receiver may not operate in lock-step. In particular,
the OP.start-ind
may not be
delivered to the receiving XML protocol processor until the sending
XML protocol processor has issued the
MSG.req
or even the
OP.end-req
. An alternative way of saying this is that a
binding may choose to delay making an underlying protocol
connection until a message needs to be sent.
The following tables show how the binding primitives might map onto the HTTP protocol actions on the initiator and responder for a request-response message exchange, time increases moving down the tables.
| Binding Primitive | Binding Action |
| OP.start-req | |
| OP.start-conf | |
| MSG.req | |
| Send POST request | |
| Receive POST results | |
| MSG.ind | |
| OP.end-req | |
| OP.end-conf |
| Binding Primitive | Binding Action |
| Receive POST request | |
| OP.start-ind | |
| OP.start-resp | |
| MSG.ind | |
| MSG.req | |
| Send POST results | |
| OP.end-ind | |
| OP.end-resp |
The above assumes use of HTTP persistent connections.
The following tables show how the binding primitives might map onto the SMTP protocol actions on the initiator and receiver for a simple one-way message exchange, time increases moving down the tables.
| Binding Primitive | Binding Action |
| OP.start-req | |
| Open SMTP session | |
| OP.start-conf | |
| MSG.req | |
| Send mail message | |
| OP.end-req | |
| Close SMTP session | |
| OP.end-conf |
| Binding Primitive | Binding Action |
| Begin SMTP transaction | |
| Receive mail message | |
| End SMTP transaction | |
| OP.start-ind | |
| OP.start-resp | |
| MSG.ind | |
| OP.end-ind | |
| OP.end-resp |
Underlying protocols may provide various levels of functionality to the binding. It is the responsibility of the binding to implement a mapping between XML protocol service primitives and underlying protocol primitives. The mapping should make the best use of the facilities of the underlying protocol and maximise efficiency where possible, e.g. connection setup is generally an expensive operation - bindings for connection oriented protocols should attempt to minimise the number of connections made for a given message exchange pattern. In particular, when defining a mapping the following need to be specified:
| Protocol |
The binding should identify the exact protocol to which XML protocol is being bound including a version. Examples might be HTTP/1.1 or SMTP[RFC821] |
| Addressing |
The binding needs to show how to specify an XML protocol processor's address with an URL. |
| Message Passing |
The binding needs to specify unambiguously how to use the underlying protocol to pass a whole XML Protocol message to a node specified by a given address. Depending on the underlying protocol capabilities, the specification may need to detail the following:
|
| Message Exchange Pattern(s) |
The binding needs to specify how underlying protocol sessions are used in common message exchange patterns including one-way and request-response. Editorial note [Question: what other message exchange patterns should we specify here ?]Here, protocol session means a unit of communication in the underlying protocol, in HTTP this maps to a single request/response, in SMTP a session only covers a single act of sending a message or a single act of receiving a message. In BEEP the session would possibly map to a channel that would be capable of many different message exchange patterns. |
| Message Ordering Characteristics |
The binding needs to specify what message ordering characteristics the underlying protocol supports. e.g. If two messages are sent in the same direction in the same session is their order of arrival guaranteed to be the same as the order in which they were sent. |
| Error Handling |
The binding needs to specify how errors in the underlying protocol will be handled. A non-exhaustive list of things to consider here is: connection errors, addressing errors, message transmission errors, abnormal termination. |
Each of these underlying protocols supports different features and capabilities and it is not plausible or desirable to provide a detailed abstraction that captures the full range of diversity. The core of XML protocol in respect of the exchange of XML protocol messages takes a lowest common denominator approach by regarding the underlying channel as potential lossy and capable of mis-ordering and duplication. Underlying protocols may offer better assurances of delivery probability, delivery ordering and at-most once delivery behaviour.
In the service abstraction provided above, an abstract parameter known as BindingContext is introduced. The primary purpose of BindingContext is to act as a collecting 'bucket' for parameters that control the functionality of the particular set of underlying protocols available at any given node.
It is expected that the authors of XML Protocol binding specifications will add structure beneath BindingContext to cover the features and capabilities of the underlying protocol being bound. This may also include a descriptor of the ordering, loss and duplication properties of the underlying protocol, although this should be treated with caution in multi-hop scenarios.
Some BindingContext extensions may be of more general applicability than just a single binding. For example, the references to user ids, private keys and public certificates necessary for SSL and HTTPS could be shared between both bindings (were they to exist).
One would therefore expect the structure under BindingContext to grow along the lines of:
BindingContext.Shared //A substructure for information shared by several bindings
BindingContext.HTTP //A substructure for information related to HTTP
BindingContext.SMTP //....
....and so on.
The manipulation of fields within the BindingContext may be driven from within, for example, an intermediary XML protocol application on the basis of constructs carried as XML protocol message blocks within the message being carried.
Editorial note Hopefully this captures the general idea behind BindingContext... the details will evolve over time... indeed they will evolve as bindings get described.Another role of an XML protocol binding is to invoke the services of underlying protocols and to introduce any mechanism required to map between the semantics of the underlying protocol and those of the XML protocol core message delivery operations XMLP_UnitData. The attachment of arbitrary content to an XML protocol message is one facet of this mapping.
The core XML protocol messaging services intrinsically handle arbitrary attachments through the use of the Attachments parameter. The expectation is that the design of XML protocol WILL specify a means for encoding arbitrary content and carrying it within an XML protocol envelope. This mechanism will leverage any pre-existing work within XML Schema, and will also provide mechanisms for embedding complete, arbitrary, XML documents within the outer XML protocol message envelope (itself an XML construct).
Some underlying protocols will support more efficient ways of carrying arbitrary content and or multiple XML documents. The normative bindings to an underlying protocol MUST define the mechanism used by that binding to carry attachments containing arbitrary content. In the absence of any statement to the contrary in the definition of a particular protocol binding, the default XML based encoding for arbitrary content attachments will be taken as having been specified. Any other scheme specified for a particular binding must have functional capabilities at least as capable as the default XML based encoding scheme, in particular it must be possible to reference the individual attachments from within the XML protocol message envelope.
This document is the work of the W3C XML Protocol Working Group.
Members of the Working Group are (at the time of writing, around July 2001, and by alphabetical order): Yasser al Safadi (Philips Research), Vidur Apparao (Netscape), Don Box (DevelopMentor), David Burdett (Commerce One), Charles Campbell (Informix Software), Alex Ceponkus (Bowstreet), Michael Champion (Software AG), David Clay (Oracle), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Ron Daniel (Interwoven), Glen Daniels (Allaire), Doug Davis (IBM), Ray Denenberg (Library of Congress), Paul Denning (MITRE Corporation), Frank DeRose (TIBCO Software, Inc.), Brian Eisenberg (Data Channel), David Ezell (Hewlett-Packard), James Falek (TIBCO Software, Inc.), David Fallside (IBM), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems), Dietmar Gaertner (Software AG), Scott Golubock (Epicentric), Rich Greenfield (Library of Congress), Martin Gudgin (Develop Mentor), Hugo Haas (W3C), Marc Hadley (Sun Microsystems), Mark Hale (Interwoven), Randy Hall (Intel), Gerd Hoelzing (SAP AG), Oisin Hurley (IONA Technologies), Yin-Leng Husband (Compaq), John Ibbotson (IBM), Ryuji Inoue (Matsushita Electric Industrial Co., Ltd.), Scott Isaacson (Novell, Inc.), Kazunori Iwasa (Fujitsu Software Corporation), Murali Janakiraman (Rogue Wave), Mario Jeckle (Daimler-Chrysler Research and Technology), Eric Jenkins (Engenia Software), Mark Jones (AT&T), Jay Kasi (Commerce One), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Jacek Kopecky (IDOOX s.r.o.), Alan Kropp (Epicentric), Yves Lafon (W3C), Tony Lee (Vitria Technology Inc.), Michah Lerner (AT&T), Richard Martin (Active Data Exchange), Noah Mendelsohn (Lotus Development), Nilo Mitra (Ericsson Research Canada), Jean-Jacques Moreau (Canon), Masahiko Narita (Fujitsu Software Corporation), Mark Needleman (Data Research Associates), Eric Newcomer (IONA Technologies), Henrik Frystyk Nielsen (Microsoft Corporation), Mark Nottingham (Akamai Technologies), David Orchard (JamCracker), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Andreas Riegg (Daimler-Chrysler Research and Technology), Hervé Ruellan (Canon), Marwan Sabbouh (MITRE Corporation), Shane Sesta (Active Data Exchange), Miroslav Simek (IDOOX s.r.o.), Simeon Simeonov (Allaire), Nick Smilonich (Unisys), Soumitro Tagore (Informix Software), James Tauber (Bowstreet), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Randy Waldrop (WebMethods), Ray Whitmer (Netscape), Volker Wiechers (SAP AG), Stuart Williams (Hewlett-Packard), Amr Yassin (Philips Research) and Dick Brooks (Group 8760).
Previous Members were: Eric Fedok (Active Data Exchange) Susan Yee (Active Data Exchange) Alex Milowski (Lexica), Bill Anderson (Xerox), Ed Mooney (Sun Microsystems), Mary Holstege (Calico Commerce), Rekha Nagarajan (Calico Commerce), John Evdemon (XML Solutions), Kevin Mitchell (XML Solutions), Yan Xu (DataChannel) Mike Dierken (DataChannel) Julian Kumar (Epicentric) Miles Chaston (Epicentric) Bjoern Heckel (Epicentric) Dean Moses (Epicentric) Michael Freeman (Engenia Software) Jim Hughes (Fujitsu Software Corporation) Francisco Cubera (IBM), Murray Maloney (Commerce One), Krishna Sankar (Cisco), Steve Hole (MessagingDirect Ltd.) John-Paul Sicotte (MessagingDirect Ltd.) Vilhelm Rosenqvist (NCR) Lew Shannon (NCR) Henry Lowe (OMG) Jim Trezzo (Oracle) Peter Lecuyer (Progress Software) Andrew Eisenberg (Progress Software) David Cleary (Progress Software) George Scott (Tradia Inc.) Erin Hoffman (Tradia Inc.) Conleth O'Connell (Vignette) Waqar Sadiq (Vitria Technology Inc.) Tom Breuel (Xerox) David Webber (XMLGlobal Technologies) Matthew MacKenzie (XMLGlobal Technologies) and Mark Baker (Sun Microsystems).
We also wish to thank all the people who have contributed to discussions on xml-dist-app@w3.org.


Installation
Requirements #
Solspace Facebook Connect meets the same requirements as listed on the ExpressionEngine Requirements page.
- ExpressionEngine 3.3.x - 3.4.x
- PHP 5.3.10 or later
- cURL
- MySQL 5.0.3 or later
- Windows and OS X browsers:
- Chrome 21 or later
- Firefox 28 or later
- Safari 9.0 or later
- Internet Explorer 11 or later
- Microsoft Edge
Installing Instructions #
- Within the /system/user/addons/ directory, copy the fbc folder into your sites ./system/user/addons/ directory.
- Within the /themes/user/ directory, copy the fbc folder into your sites ./themes/user/ directory.
- Go to the Add-On Manager area in the ExpressionEngine control panel, scroll to down to the Third Party Add-Ons section, and find Facebook Connect in the list, and click Install.
- Setup and configuring:
- To use this add-on, you'll need to create a Facebook App.
- The Control Panel area allows you adjust preferences and run diagnostics.
- Be sure to read over the Overview & Important Notes and Behind the Scenes documentation for this add-on.
- If you wish to install the demo templates, click on the Demo Templates tab inside the control panel area.


{% extends "com/cardform.html" %} {% block title %}
The password change link was invalid, possibly because it has already been used. Please request a new password, or login again.
{% endif %} {% endblock %} {% block card_action %} {% if not validlink %} {% endif %} {% endblock %} {% block before_card_form %}


Business Psychology
- Fundamentals: Definition of Psychology
- Major Perspectives of Psychology
- Subfields of Psychology, Psychology in Business
- Job Analysis: Job-oriented Approach
- Person-oriented Approach, Purposes of Job Analysis
- Methods of Job Analysis, Job Evaluation
- Assessment Methods for Selection and Placement
- Psychological Tests: Ability Test
- Psychological Tests: Intelligence Test
- Psychological Tests: Personality Test
- Psychological Tests: Vocational Interest Test
- Training and Development: Training Need Analysis
- Training Designs, Training Methods, Evaluation of Training
- Theories of Employee Motivation: Need Theories, Reinforcement Theory
- Expectancy Theory, Goal Setting Theory
- Job Attitude and Emotion: Nature of Job Satisfaction
- Assessment of Job Satisfaction, Antecedents of Job Satisfaction
- Potential Effects of Job Satisfaction
- Organizational Commitment
- Emotion at work
- Productive and Counterproductive Employee Behavior
- Productive Behavior, Job Performance
- Counterproductive Behavior
- Withdrawal, Aggression, Mistreatment
- Sabotage, and Theft
- Occupational Health Psychology
- Occupational Health and Safety
- Work Schedules, Occupational Stress, Work-Family Conflict
- Burnout, Hawthorne Studies
- Approaches to the Understanding of Leadership Trait Approach
- Leader Behavior Approach
- Contingency Theory
- Path-Goal Theory
- Leader-Member Exchange (LMX) Theory
- Transformational Leadership Theory
- Organizational Development and Theory
- Organizational Development Employee Acceptance of Change
- Management by Objectives
- Survey Feedback
- Team Building
- T-Group
- Effectiveness of Organizational Development
- Organizational Theories
- Bureaucracy
- Theory X and Theory Y
- Open System Theory
- Socio-technical System Theory


++=
BufSet
Buffer
Dict
+=
Array
RefBuf
BufSet
Buffer
Dict
-
FilterOrdered
--=
BufSet
Buffer
Dict
-=
Array
BufSet
Buffer
Dict
:=
Channel
<<
WriteChannel
<<>>
Channel
>>
ReadChannel
|
ReadChannel


WPA_SUPPLICANT.CONF
Section: (5)Updated: 07 September 2010
Index Return to Main Contents
NAME
wpa_supplicant.conf - configuration file for wpa_supplicantOVERVIEW
wpa_supplicant is configured using a text file that lists all accepted networks and security policies, including pre-shared keys. See the example configuration file, probably in /usr/share/doc/wpa_supplicant/, for detailed information about the configuration format and supported fields.
All file paths in this configuration file should use full (absolute, not relative to working directory) path in order to allow working directory to be changed. This can happen if wpa_supplicant is run in the background.
Changes to configuration file can be reloaded be sending SIGHUP signal to wpa_supplicant ('killall -HUP wpa_supplicant'). Similarly, reloading can be triggered with the wpa_cli reconfigure command.
Configuration file can include one or more network blocks, e.g., one for each used SSID. wpa_supplicant will automatically select the best network based on the order of network blocks in the configuration file, network security level (WPA/WPA2 is preferred), and signal strength.
QUICK EXAMPLES
- 1.
-
WPA-Personal (PSK) as home network and WPA-Enterprise with
EAP-TLS as work network.
-
# allow frontend (e.g., wpa_cli) to be used by all users in 'wheel' group ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel # # home network; allow all valid ciphers network={ ssid="home" scan_ssid=1 key_mgmt=WPA-PSK psk="very secret passphrase" } # # work network; use EAP-TLS with WPA; allow only CCMP and TKIP ciphers network={ ssid="work" scan_ssid=1 key_mgmt=WPA-EAP pairwise=CCMP TKIP group=CCMP TKIP eap=TLS<EMAIL_ADDRESS>ca_cert="/etc/cert/ca.pem" client_cert="/etc/cert/user.pem" private_key="/etc/cert/user.prv" private_key_passwd="password" }
-
- 2.
-
WPA-RADIUS/EAP-PEAP/MSCHAPv2 with RADIUS servers that
use old peaplabel (e.g., Funk Odyssey and SBR, Meetinghouse
Aegis, Interlink RAD-Series)
-
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel network={ ssid="example" scan_ssid=1 key_mgmt=WPA-EAP eap=PEAP<EMAIL_ADDRESS>password="foobar" ca_cert="/etc/cert/ca.pem" phase1="peaplabel=0" phase2="auth=MSCHAPV2" }
-
- 3.
-
EAP-TTLS/EAP-MD5-Challenge configuration with anonymous
identity for the unencrypted use. Real identity is sent only
within an encrypted TLS tunnel.
-
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel network={ ssid="example" scan_ssid=1 key_mgmt=WPA-EAP eap=TTLS<EMAIL_ADDRESS><EMAIL_ADDRESS>password="foobar" ca_cert="/etc/cert/ca.pem" phase2="auth=MD5" }
-
- 4.
-
IEEE 802.1X (i.e., no WPA) with dynamic WEP keys
(require both unicast and broadcast); use EAP-TLS for
authentication
-
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel network={ ssid="1x-test" scan_ssid=1 key_mgmt=IEEE8021X eap=TLS<EMAIL_ADDRESS>ca_cert="/etc/cert/ca.pem" client_cert="/etc/cert/user.pem" private_key="/etc/cert/user.prv" private_key_passwd="password" eapol_flags=3 }
-
- 5.
-
Catch all example that allows more or less all
configuration modes. The configuration options are used based
on what security policy is used in the selected SSID. This is
mostly for testing and is not recommended for normal
use.
-
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel network={ ssid="example" scan_ssid=1 key_mgmt=WPA-EAP WPA-PSK IEEE8021X NONE pairwise=CCMP TKIP group=CCMP TKIP WEP104 WEP40 psk="very secret passphrase" eap=TTLS PEAP TLS<EMAIL_ADDRESS>password="foobar" ca_cert="/etc/cert/ca.pem" client_cert="/etc/cert/user.pem" private_key="/etc/cert/user.prv" private_key_passwd="password" phase1="peaplabel=0" ca_cert2="/etc/cert/ca2.pem" client_cert2="/etc/cer/user.pem" private_key2="/etc/cer/user.prv" private_key2_passwd="password" }
-
- 6.
-
Authentication for wired Ethernet. This can be used with
wired or roboswitch interface
(-Dwired or -Droboswitch on command line).
-
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel ap_scan=0 network={ key_mgmt=IEEE8021X eap=MD5 identity="user" password="password" eapol_flags=0 }
-
CERTIFICATES
Some EAP authentication methods require use of certificates. EAP-TLS uses both server side and client certificates whereas EAP-PEAP and EAP-TTLS only require the server side certificate. When client certificate is used, a matching private key file has to also be included in configuration. If the private key uses a passphrase, this has to be configured in wpa_supplicant.conf ("private_key_passwd").
wpa_supplicant supports X.509 certificates in PEM and DER formats. User certificate and private key can be included in the same file.
If the user certificate and private key is received in PKCS#12/PFX format, they need to be converted to suitable PEM/DER format for wpa_supplicant. This can be done, e.g., with following commands:
-
# convert client certificate and private key to PEM format openssl pkcs12 -in example.pfx -out user.pem -clcerts # convert CA certificate (if included in PFX file) to PEM format openssl pkcs12 -in example.pfx -out ca.pem -cacerts -nokeys
SEE ALSO
wpa_supplicant(8) openssl(1)
Index
This document was created by man2html, using the manual pages.
Time: 05:34:00 GMT, December 24, 2015


Bookmarklets are little javascript links that live in the bookmarks toolbar of your browser. Drag one of the bookmarklet links bellow to your browser's bookmarks to easily save links, code snippets or notes when clicked.
You can make a
text selection on the page, to use it as
description when choosing to create a
new bookmark or as
code
when choosing to create a new snippet out of it.
If no text selection, then the
new bookmark dialog is presented. The
meta:description, if available, will be used for the
description field


All you need on one page!
What is ZABBIX?


--- date: 2010-02-19T00:00:00Z published: true title: Linode and Ubuntu 9.10 are the bomb. url: /2010/02/19/linode-and-ubuntu-9-10-are-the-bomb-/ ---
I just installed pretty much everything I need using a apt-get and ruby gems - here's the script:
And that is awesome - that box is pretty much ready to go now. That took 2 hours - mostly because I did it 2 times to make sure I got it right.


| << Error descriptions and error suppression << | ^^ Table of Contents ^^ | >> How to devise effective test cases >> |
The "meat" of BidiChecker is the actual bidi checks. BidiChecker runs a series of checkers on the web page DOM, each of which scans for a particular kind of error and generates error reports. This section catalogs the checks implemented so far and the errors they produce.
Checks whether the overall declared directionality of the web page (or root element being checked) is the same as that intended by the developer (as specified in the call to BidiChecker). If, for example, the developer specified an intended directionality of RTL, but the page body or root element is LTR, an error will be reported. This type of error is always severity level 1.
[1] Overall directionality not LTR
More information about declaring the overall page directionality.
Checks for strongly-directional characters (such as English, Hebrew or Arabic letters) which are in an area declared to have the opposite directionality. Each run of opposite-directionality text (possibly mixed in with neutrals) is reported as an error.
When testing bidi support, RTL text is sometimes simulated by surrounding English letters with the Unicode control characters RLO and PDF, forcing the English text to behave like right-to-left characters. This is sometimes known as "Fake Bidi" or "Fake RTL". Starting from revision 2, the undeclared opposite-directionality checker also generates an error for fake-RTL text in an LTR context.
Undeclared opposite-directionality text is a problem because
Undeclared opposite-directionality text is not necessarily a problem. There are messages that you never want translated, e.g. "Gmail". If their text does not fall into one of the troublesome categories above and does not happen to lie next to another undeclared opposite-directionality phrase, no visible problem will result.
[2] Undeclared RTL text: 'שלום'
followed by '.' in

If the run of opposite-directionality text is immediately preceded or followed by a run of neutral characters, those characters are reported as the error context fields and the error severity is set at level 2. If there is no such adjacent run of neutral characters, the error severity is 3. (But see the next section.)
More information about declaring opposite-directionality text.
In certain circumstances, the severity of undeclared opposite-directionality text errors is demoted to 4. If an element other than the root element has an explicitly-declared directionality (i.e., a "dir" attribute), and that element also does not contain any block-level elements (i.e., it is the lowest-level block in its subtree), then bidi errors inside that element's subtree are assigned the lowest severity. This is based on the assumption that the explicit declaration of directionality indicates that the code which generated this part of the page has somehow deliberately assessed its directionality. Rather than second-guess the developers, we demote the severity of error reports in that subtree. It may, for example, represent a block of user-generated content included from an external website; errors in such content are not the responsibility of the application.
This heuristic is far from perfect, and we may revisit it as necessary.
Checks text-valued attributes, such as input fields, button labels and tooltips ("title" and "alt" attributes), looking for those which have strongly-directional characters (such as English, Hebrew or Arabic letters) with the opposite of the declared directionality, while containing no letters with the declared directionality itself. Each such attribute is reported as an error.
This set of checks was introduced in Revision 2, and is not active in tests run at Revision 1.
The following attribute types are checked:
These attributes have several points in common:
Note that when the attribute value contains both LTR and RTL characters, it is not flagged as an error regardless of its declared directionality. This is because only one directionality can be declared for the whole value, and different applications use different criteria to estimate the directionality of mixed-directionality text. That it is not flagged as an error does not necessarily mean that there is no problem. In fact, when the wrong directionality is declared for a mixed-directionality value, very severe garbling usually results. We just have no way of knowing whether there is a problem or not, and the application has no way of avoiding the situation.
This set of checks can produce errors of the following types:
As with undeclared opposite-directionality inline text, text garbling can affect text attributes with the wrong directionality declaration. Also, entering text into an input or textarea with the wrong directionality is a real pain for the user.
Ideally, text inputs (<input type=text|search> and <textarea>) in which the user could enter a value of either direction should change their directionality automatically on the fly depending on the value the user has entered so far. Functions which implement this can be found in Javascript libraries and template systems, such as Closure's goog.i18n.bidi.estimateDirection().
In cases where the intended directionality of the title attribute does not match that of some other text property, such as an input's text content or a button's label or an image's alt attribute, place a span or div around the element, move the title attribute there, and give the two elements different directionalities.
If the text value is known to contain only one direction of text, and not to start or end with punctuation or other direction-neutral characters, the appearance of the text will not in practice be different when the wrong directionality is declared. In such cases, the error severity is set at level 3; otherwise, it will be 2.
However, if the element with the text-valued attribute itself has a "dir" attribute (or a "direction" style applied directly or via a style file), the severity will be demoted to 4. This is based on the assumption that the explicit declaration of directionality indicates that the code which generated this part of the page has somehow deliberately assessed its directionality. Rather than second-guess the developers, we demote the severity of error reports for that element.
On the other hand, errors in textarea or input values always get severity 1 due to the nuisance to users of entering data in a box with the wrong directionality.
[2] Undeclared RTL textarea value: 'שלום'
followed by '.' in
<textarea>
[3] Undeclared LTR input value: 'Shalom' in
<input type='text' value='Shalom'>
[4] Undeclared LTR title text: 'Hello' in

[2] Undeclared RTL alt text: 'שלום' followed by
'!' in

[2] File input not LTR in
<input type='file'>
When an opposite-directionality element is followed by a number (possibly with intervening neutral characters), the standard Unicode bidi algorithm extends the opposite-directionality region to encompass the subsequent number. This can, and often does, cause text garbling. For examples, follow the link below.
We identify spillover by the following heuristic criteria:
[2] Declared LTR spillover to
number: '1' preceded by 'The Unbearable Light…' in

Spillover errors have severity level 2. As with undeclared opposite-directionality text, errors in an area of explictly-declared directionality are demoted to severity level 4 (see above).
More information about preventing spillover errors.
| << Error descriptions and error suppression << | ^^ Table of Contents ^^ | >> How to devise effective test cases >> |


@** * Yobi, Project Hosting SW * * Copyright 2014 NAVER Corp. * http://yobi.io * * @Author Deokhong Kim * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. **@ @(menuType:utils.MenuType, project:Project, org:Organization) @import utils._ @isActiveMenu(m_type:MenuType) = @{ if(m_type == menuType){ "active" } } @appFeedbackUrl() = @{ play.Configuration.root().getString("application.feedback.url") } @makeSearchLink() = @{ if(project != null) { routes.SearchApp.searchInAProject(project.owner, project.name) } else if (org !=null) { routes.SearchApp.searchInAGroup(org.name) } else { routes.SearchApp.searchInAll() } }
@Html(Messages("error.unsupported.ie"))


Sometimes it takes more than just hard work to get the task done - it takes team work! Whether a dedicated member or the project lead, a philosphy of mine is "Universus Disco Veritas." In this case, my truth is a RESTful project completion.
As a Full Stack Web Developer these are the languages that I am proficient in. But like many things in life, we can't just stop there! I look forward to alway expanding my knowledge base. Always searching for new ways to be innovative.
A special thanks to Wyncode Academy for not only exposing me to the growing subculture of the Miami Tech Industy, But also giving me the tools and resources to continue to educated myself as well as help mold the Global Tech Community.


[Some space left here for the most common navbars]
▶...◀
cosnole.alert says
1
OK
cosnole.alert
Browser Extension to shows logs, errors, and warnings as toast messages to help you catch bugs faster
It also extends browser's console object with the alert() function
Ok
With "cosnole.alert" you can:
reflect console.log() calls in the toast messages
trigger window.alert() on all console.log() calls
use console.alert() instead of window.alert()
define custom global methods to call alert()
use regexp or a "stop-word" to call alert()
use allow/block-lists or enable it for localhost only
use it to see console.log() events called in an iframe
The extension provides 3 modes to use
you can switch the mode depending on your needs and the web-site's configurations
Default mode
[+]provides all the features
[+]injects <script> tag onto the page to extend console and window objects
[+]can show both alert and toast: simultaneously or separately, depending on the called method
[-]requires page reload to apply any options' update
[-]will not work on sites with a good CSP(Content Security Policy) configuration
[-]may "loose" some events on fast, small or cached website due to the asynchronous nature of JavaScript
Toasts Only
TBD. Not yet implemented...
[+]does not inject <script> tag, but instead uses browser's API only
[+]works on any website and is not affected by CSP(Content Security Policy)
[+]cannot "loose" events but will show them with a short delay
[+]You do not need to reload the page to pause this extension or to apply any options' update
[-]can not extend console or window object to add custom or to modify existent methods
Simple mode
simple as a pay:
[+]injects <script> tag onto the page to add alert() method to the console object
[+]most likely will not "loose" events on a fast, small or cached website as it's just a one line of JavaScript code
[-]implements only one single feature — maps alert() to console.alert() method
[-]requires page reload to pause it, but in most cases you do not need to pause it at all
[-]will not work on sites with a good CSP(Content Security Policy) configuration


In-depth Stories You Don't See Elsewhere About Topics You Want to Read!
All Access + Weekly Delivery.
Choose A Membership That's Perfect for You!
What if all the constitutional successors are incapacitated? Standby orders were issued more than three weeks ago to protect Washington and also prepare for the possibility of some form of martial law.
While the fate of the 2020 Tokyo Olympics hangs in the balance due to the coronavirus pandemic, here's a look at other cities that have succeeded in creating structures that have stood the test of time and continue to be as awe-inspiring and groundbreaking as the games themselves.
While the fate of the 2020 Tokyo Olympics hangs in the balance due to the coronavirus pandemic, here's a look at other cities that have succeeded in creating structures that have stood the test of time and continue to be as awe-inspiring and groundbreaking as the games themselves.
While the fate of the 2020 Tokyo Olympics hangs in the balance due to the coronavirus pandemic, here's a look at other cities that have succeeded in creating structures that have stood the test of time and continue to be as awe-inspiring and groundbreaking as the games themselves.
There have been nearly 200,000 infections reported worldwide and multiple governments have imposed national lockdowns to slow the spread.
There have been nearly 200,000 infections reported worldwide and multiple governments have imposed national lockdowns to slow the spread.
Is Bernie Sanders Right About Medicare For All?
Is Bernie Sanders Right About Medicare For All?
Is Bernie Sanders Right About Medicare For All?
Is Bernie Sanders Right About Medicare For All?
Is Bernie Sanders Right About Medicare For All?
Is Bernie Sanders Right About Medicare For All?
Is Bernie Sanders Right About Medicare For All?
Is Bernie Sanders Right About Medicare For All?
Aldrin was one of the first two humans to walk on the lunar surface.
Aldrin was one of the first two humans to walk on the lunar surface.
Aldrin was one of the first two humans to walk on the lunar surface.
Aldrin was one of the first two humans to walk on the lunar surface.
Aldrin was one of the first two humans to walk on the lunar surface.
Aldrin was one of the first two humans to walk on the lunar surface.
Aldrin was one of the first two humans to walk on the lunar surface.
Aldrin was one of the first two humans to walk on the lunar surface.
WWE Monday Night RAW Results: 'Stone Cold' Steve Austin to Return Tonight
WWE Monday Night RAW Results: 'Stone Cold' Steve Austin to Return Tonight
WWE Monday Night RAW Results: 'Stone Cold' Steve Austin to Return Tonight
WWE Monday Night RAW Results: 'Stone Cold' Steve Austin to Return Tonight
WWE Monday Night RAW Results: 'Stone Cold' Steve Austin to Return Tonight
WWE Monday Night RAW Results: 'Stone Cold' Steve Austin to Return Tonight
WWE Monday Night RAW Results: 'Stone Cold' Steve Austin to Return Tonight
WWE Monday Night RAW Results: 'Stone Cold' Steve Austin to Return Tonight
WWE Monday Night RAW Results: 'Stone Cold' Steve Austin to Return Tonight
WWE Monday Night RAW Results: 'Stone Cold' Steve Austin to Return Tonight
WWE Monday Night RAW Results: 'Stone Cold' Steve Austin to Return Tonight Tonight
WWE Monday Night RAW Results: 'Stone Cold' Steve Austin to Return Tonight
All Access + Weekly Delivery.
Choose A Membership That's Perfect for You!
 Sign up for our newsletter and start making sense of the world around you.
SIGN UP


Click on the extra One Piece character on the left.
If you lose and want to play again, just refresh tha page!


Service/Delicious.php
Zend Framework
LICENSE
This source file is subject to the new BSD license that is bundled
with this package in the file LICENSE.txt.
It is also available through the world-wide-web at this URL:
http://framework.zend.com/license/new-bsd
If you did not receive a copy of the license and are unable to
obtain it through the world-wide-web, please send an email
to<EMAIL_ADDRESS>so we can send you a copy immediately.
- category
- Zend
- copyright
- Copyright (c) 2005-2011 Zend Technologies USA Inc. (http://www.zend.com)
- license
-
New BSD License
- package
- Zend_Service
- subpackage
- Delicious
- version
- $Id: Delicious.php 23775 2011-03-01 17:25:24Z ralph $
\Zend_Service_Delicious
Zend_Service_Delicious is a concrete implementation of the del.icio.us web service
- category
- Zend
- copyright
- Copyright (c) 2005-2011 Zend Technologies USA Inc. (http://www.zend.com)
- license
-
New BSD License
- package
- Zend_Service
- subpackage
- Delicious
Constants
Properties
float
$_lastRequestTime= '0'
staticMicrotime of last request
Default value0
Details
- Type
- float
\Zend_Service_Rest
$_rest= ''
Zend_Service_Rest instance
Details
- Type
- \Zend_Service_Rest
Methods
__construct(
string $uname
=
null, string $pass
=
null
)
:
void
Constructs a new del.icio.us Web Services Client
Parameters
| Name |
Type |
Description |
| $uname |
string |
Client username |
| $pass |
string |
Client password |
_xmlResponseToArray(
\DOMDocument $response, string $root, string $child, string $attKey, string $attValue
)
:
array
staticTransform XML string to array
Parameters
| Name |
Type |
Description |
| $response |
\DOMDocument |
|
| $root |
string |
Name of root tag |
| $child |
string |
Name of children tags |
| $attKey |
string |
Attribute of child tag to be used as a key |
| $attValue |
string |
Attribute of child tag to be used as a value |
Returns
Throws
getBundles(
)
:
array
Get all bundles, returning an array with bundles as keys and array of tags as values
Returns
| Type |
Description |
| array |
list of bundles |
getDates(
string $tag
=
null
)
:
array
Get number of posts by date
Returns array where keys are dates and values are numbers of posts
Parameters
| Name |
Type |
Description |
| $tag |
string |
Optional filtering by tag |
Returns
| Type |
Description |
| array |
list of dates |
getPosts(
string $tag
=
null, \Zend_Date $dt
=
null, string $url
=
null
)
:
\Zend_Service_Delicious_PostList
Get posts matching the arguments
If no date or url is given, most recent date will be used
Parameters
| Name |
Type |
Description |
| $tag |
string |
Optional filtering by tag |
| $dt |
\Zend_Date |
Optional filtering by date |
| $url |
string |
Optional filtering by url |
Returns
Throws
getRecentPosts(
string $tag
=
null, string $count
=
15
)
:
\Zend_Service_Delicious_PostList
Parameters
| Name |
Type |
Description |
| $tag |
string |
Optional filtering by tag |
| $count |
string |
Maximum number of posts to be returned (default 15)
|
Returns
getTags(
)
:
array
Get all tags, returning an array with tags as keys and number of corresponding posts as values
Returns
| Type |
Description |
| array |
list of tags |
getUrlDetails(
string $url
)
:
array
Get details on a particular bookmarked URL
Returned array contains four elements:
- hash - md5 hash of URL
- top_tags - array of tags and their respective usage counts
- url - URL for which details were returned
- total_posts - number of users that have bookmarked URL
If URL hasen't been bookmarked null is returned.
Parameters
| Name |
Type |
Description |
| $url |
string |
URL for which to get details |
Returns
getUserPosts(
string $user, int $count
=
null, string $tag
=
null
)
:
\Zend_Service_Delicious_PostList
Parameters
| Name |
Type |
Description |
| $user |
string |
Owner of the posts |
| $count |
int |
Number of posts (default 15, max. 100)
|
| $tag |
string |
Optional filtering by tag |
Returns
getUserTags(
string $user, int $atleast
=
null, int $count
=
null, string $sort
=
alpha
)
:
array
Returned array has tags as keys and number of posts as values
Parameters
| Name |
Type |
Description |
| $user |
string |
Owner of the posts |
| $atleast |
int |
Include only tags for which there are at least ### number of posts |
| $count |
int |
Number of tags to get (default all)
|
| $sort |
string |
Order of returned tags ('alpha' || 'count')
|
Returns
makeRequest(
string $path, array $parms
=
array, string $type
=
xml
)
:
mixed
Handles all GET requests to a web service
Parameters
| Name |
Type |
Description |
| $path |
string |
Path |
| $parms |
array |
Array of GET parameters |
| $type |
string |
Type of a request ("xml"|"json")
|
Returns
| Type |
Description |
| mixed |
decoded response from web service |
Throws
setAuth(
string $uname, string $pass
)
:
\Zend_Service_Delicious
Set client username and password
Parameters
| Name |
Type |
Description |
| $uname |
string |
Client user name |
| $pass |
string |
Client password |
Returns


GetHTTPHeader()
Syntax
Result$ = GetHTTPHeader(URL$)Description
Get the HTTP headers of the given URL.
Parameters
URL$ The URL for the query. The URL must be fully qualified, and must include the "http://" or "https://" prefix.
Return value
Returns a string containing the header lines. Each line ends with a Chr(10) character. StringField() can be used to split it into several strings.
The content of the headers are dependent on the type of server and therefore their contents vary, but the header that is returned by that server, provides very useful information about the file, such as the date, the server type, the version, and more.
Remarks
InitNetwork() has to be called before using this command.
Example
InitNetwork() Header$ = GetHTTPHeader("http://www.purebasic.com/index.php") Repeat Index+1 Line$ = StringField(Header$, Index, #LF$) Debug Line$ Until Line$ = ""Example of returned headers:HTTP/1.1 200 OK Date: Fri, 21 Mar 2008 09:49:30 GMT Server: Apache/1.3.34 (Debian) mod_vhost_online/1.1 mod_fastcgi/2.4.2 mod_log_online/0.1 X-Powered-By: PHP/4.4.8-1 Content-Type: text/html
See Also
ReceiveHTTPFile(), URLEncoder()
Supported OS
All


I've watched Dr. Claude Steele's lectures on stereotype threat. I have to say I'm a little torn on the subject. I'm not sure if I buy into it as a phenomenon on it's own, but he does have a lot of research that seems to back it up. Research and statistics are easy to manipulate, though. I haven't really had time to look the specific studies he mentioned and their methodology though, so I have no reason to doubt them... yet. The only thing I have to go on right now is personal experience.
With a name like Mary, you probably assumed I'm a woman. If you did, you'd be correct. I grew up in a home full of engineers and scientists with a lot of engineers and scientists in our lineage, both male and female, on my father's side. Maybe this is why I never perceived stereotype threat in my life, or maybe it's a generational thing. I decided to discuss it with my mother, a self-fulfilled woman who's started many successful businesses. I thought perhaps she'd share my confusion in stereotype threat.
 She'd wanted to join the football team, and was good enough to join, according to the coach, but was forbidden by her parents. She had wanted to pursue a college degree, but was constantly reminded by her mother that the only reason women went to college was to earn a "MRS degree," meaning to find a husband.
I asked if any of this ever affected her performance in anything that she did.  I have to say, she's been extremely successful in her businesses, so maybe she did prove them all wrong.
As a result of her upbringing, my mother forbade fashion dolls in our household and encouraged all of her children to pursue anything they wanted to, with no mention of gender expectations. In contrast to my mother's childhood where girls and boys were expected to perform certain chores depending on their gender, we all had a turn at cleaning and we all had a turn at manual labor. I was extremely active and successful in my school's sports community as well as in the academic competitions such as Math Counts and In The Know, and a couple of my brothers excelled in arts and professional cooking. We never knew girls and boys weren't supposed to excel in certain things. I guess I have my mother to thank for that.
The first time in my life that I ever ran into a stereotype was in high school, at my first job at a fast food joint. One of my coworkers, Ling (not his real name,) asked what degree I was pursuing when he found out I was attending college. When I replied Computer Science, he laughed. I wasn't sure why he was laughing so I just gave him a confused look and he slowly quieted and reflected my confused look back at me. We stared at each other for about 20 seconds before he broke the silence with "but you're a girl." Apparently this caused an even more confused look to overtake my face, because after another awkward silence he explained, "girls don't do that kind of thing." Another awkward silence followed which was broken by me with, "what are you talking about?" He never answered, instead choosing to look embarassed and walk away. Needless to say, I was confused the rest of the day.
Maybe I've been lucky that I never ran into stereotyping until that particular time. Dr. Steele mentioned that the steroetype threat phenomenon did not occur in all girls' schools, meaning that people who were insulated from it tended to not be affected by it. Maybe my ignorance of stereotypes shielded me from ever experiencing it. Even after that point, I never let it affect me. I let Ling's comments be a reflection on him and his thinking capacities rather than my own and moved on. I can't recall any time I'd run into that kind of situation since then, so it exists only as an outlier in my experience.
All of that being said, I'm only speaking as a woman. I don't know if I'd necessarily consider myself a minority since approximately half of the population is female, like me. Perhaps someone who came from a different household and was of different ethnicity or orientation would feel differently from me. I've always appreciated other people for who they are, not their physical characteristics or where they came from. I can't claim to know their experiences or the extent of the effect of stereotype threat on them.
But maybe my lack of experience with it could be an answer. If as a culture, we focused on allowing everyone to be whoever they wanted to be, without focusing on stereotypes, maybe the phenomenon would disappear altogether. I know I'm starting with my children, just as my mother did. Thanks, mom!


Use containers to align content correctly in the middle of the page.
Below are the primary colours used in the RiskXchange pallette:
You can make the navbar either full width or contained. The contained version, used for this demo, is acheived by adding .rx-container.rx-container--no-pad
to the .rx-navbar
element.
To see this page with a full-width navbar, click here.
Forms can be created using .rx-form
. They can have a title .rx-form__title
and actions .rx-form__actions
which can contains submit buttons, etc.
Forms contain fields .rx-field
, which can contain inputs .rx-input
, selects .rx-select
, radios .rx-radio-group
and checkboxes .rx-checkbox-group
.
Fields can also include info about the field, using .rx-field__info
. Labels are created with .rx-field__label
.
Checkboxes .rx-checkbox-group
and radios .rx-radio-group
are very similar.
All tooltips .rx-tooltip
should be used within .rx-field
elements.
On mobile, they require the icon to be clicked in order to toggle the .rx-tooltip--active
selector, which shows/hides the tooltip.
| Fruit | Price | Color |
|---|---|---|
| Apple | 30p | green |
| Banana | 25p | yellow |
| Carrot | 18p | orange |
rx-loader
rx-loader--light-bg
There are two variants of the notice .rx-notice
element: success .rx-notice--success
and error .rx-notice--error
.
Try using them with icons .rx-icon
, to prevent them looking too much like inputs
Letter grades are created with .rx-grade--a
.
WIP items have grade ... can be created with .rx-grade--wip
.
Items which don't need a grade (i.e. N/A) can be created with .rx-grade--na
.
Grades come in two sizes: .rx-grade
adn .rx-grade--large
Below are examples of the RiskXchange React components.
To use them in your project, use import {Card} from 'styleguide/react'


Frank Lampard defends under-fire West Ham boss Manuel Pellegrini ahead of Chelsea trip
The Hammers manager signed the former West Ham midfielder as a player in 2014
by Sam InkersoleFormer West Ham midfielder and now Chelsea manager Frank Lampard has defended Manuel Pellegrini as the under pressure Hammers boss takes his strugglers to Stamford Bridge on Saturday.
West Ham have been on a dire run since September 22 when they last won a game, losing five and drawing two of their previous seven Premier League games to slump from fifth in the table to 17th.
Pellegrini signed Lampard as a player at Manchester City on a short-term deal prior to joining one of City's sister clubs, New York City FC, ahead of their upcoming MLS season.
The Blues manager is still making his way in the early stages of his managerial career while his Chilean counterpart in the opposite dugout this weekend has more than 30 years of experience behind him.
And Lampard has praised Pellegrini, who needs results against Chelsea and Wolves next week to avoid being axed from his job less than 18 months after arriving at the club.
Lampard said at his pre-match press conference: "He is a good man and manager, he will be working hard to turn them around. We all know the ruthless nature of the game. Every team, every owner, everyone wants to push.
"I will just do my job. We know how passionate fans are, it will be on both sides.
"I think with the Premier League it is hard to make judgements at the start of the season. It is a tough league, I have good players. We have West Ham and have good individuals, good team and manager and we have to be ready for them.
"It's a London derby, we have to be ready."


Data
The Internet
I may not know what I'm doing but I know I can figure it out


Menu
Home
Contact
LinkedIn
Dribbble
SAY HI TO ME BY EMAILING
RUBYJAZZDESIGN
@
GMAIL
.
COM
OR THINKING REALLY HARD ABOUT CATS.


---
permalink: /working/b.html
sitemap: false
custom_js:
- new.bundle.js
---
{% include blocks/hero.html %}
{% include blocks/early.html %}
{% include blocks/about.html %}
{% include blocks/testimonials.html %}
{% include blocks/cfp.html %}
{% include blocks/cfs.html %}
{% include blocks/subscribe.html %}
{% include blocks/footer.html %}


The Bottleneck Problem
Visible
Visible
Detached
Docker
Save
Sane
Broke
Mechanical failure
Mechanical failure
System failure
Create
Sane
Broke
Mechanical failure
Mechanical failure
System failure
Create
Left
Right
Sane
Broke
Mechanical failure
Mechanical failure
System failure
Create
Simulation scenerys
Scenery 1
Reverse
Scenery 2
Reverse
Scenery 3
Reverse
Scenery 4
Reverse
Scenery 5
Reverse
Scenery 6
Reverse
Scenery 7
Reverse
Scenery 8
Reverse
Scenery 9
Reverse
Scenery crash 4
Scenery crash 5
Scenery crash 6
Scenery crash 7
Scenery crash 8
Scenery crash 9
Random mode
Manual mode
See logs
Reset simulation


Finance Committee 8:30 AM
Dec 13, 2018
Board of Directors (following Committee meetings)
Dec 13, 2018
Finance Committee
Nov 28, 2018
Board of Directors
Nov 28, 2018
Finance Committee
Oct 18, 2018
Board of Directors
Oct 18, 2018
Finance Committee
Sep 13, 2018
Board of Directors (following Committee meetings)
Sep 13, 2018
Board Meeting (following Executive Session)
Sep 13, 2018
Finance Committee
Aug 23, 2018
Board of Directors
Aug 23, 2018
Finance Committee
Jun 21, 2018
Board of Directors
Jun 21, 2018
Audit Committee
Jun 21, 2018
Planning & Administration Committee
May 17, 2018
Finance Committee
May 17, 2018
Board of Directors
May 17, 2018
Planning & Administration Committee
Apr 19, 2018
Finance Committee
Apr 19, 2018
Board of Directors
Apr 19, 2018
Finance Committee
Feb 15, 2018
Board of Directors
Feb 15, 2018
Audit Committee
Feb 15, 2018
Planning & Administration Committee
Jan 18, 2018
Finance Committee
Jan 18, 2018
Compensation & Human Resources Committee
Jan 18, 2018
Board of Directors
Jan 18, 2018
Planning & Administration Committee
Dec 14, 2017
Finance Committee
Dec 14, 2017
Board of Directors
Dec 14, 2017
Finance Committee - Includes Special Finance Committee Items
Nov 29, 2017
Board of Directors
Nov 29, 2017
Planning & Administration Committee
Oct 19, 2017
Finance Committee
Oct 19, 2017
Compensation & Human Resources Committee
Oct 19, 2017
Board of Directors
Oct 19, 2017
Planning & Administration Committee
Aug 24, 2017
Finance Committee
Aug 24, 2017
Board of Directors
Aug 24, 2017
Finance Committee
Jun 22, 2017
Compensation & Human Resources Committee
Jun 22, 2017
Board of Directors
Jun 22, 2017
Audit Committee
Jun 22, 2017
Finance Committee
May 25, 2017
Board of Directors
May 25, 2017
Finance Committee
Apr 20, 2017
Compensation & Human Resources Committee
Apr 20, 2017
Board of Directors
Apr 20, 2017
Finance Committee
Mar 16, 2017
Compensation & Human Resources Committee
Mar 16, 2017
Board of Directors
Mar 16, 2017
Finance Committee (Audio Visual and Agenda Only/See separate file for backup documents)
Feb 16, 2017
Finance Committee (Agenda and backup documents only/No Audio Visual)
Feb 16, 2017
Board of Directors
Feb 16, 2017
Audit Committee
Feb 16, 2017
Planning & Administration Committee
Dec 15, 2016
Finance Committee
Dec 15, 2016
Board of Directors
Dec 15, 2016
Finance Committee Part II
Nov 30, 2016
Finance Committee Part I
Nov 30, 2016
Planning & Administration Committee
Nov 17, 2016
Finance Committee
Nov 17, 2016
Board of Directors
Nov 17, 2016
Planning & Administration Committee
Oct 20, 2016
Finance Committee
Oct 20, 2016
Board of Directors
Oct 20, 2016
Finance Committee
Sep 15, 2016
Board of Directors
Sep 15, 2016
Finance Committee
Aug 25, 2016
Board of Directors
Aug 25, 2016
Finance Committee
Jun 23, 2016
Board of Directors
Jun 23, 2016
Audit Committee
Jun 23, 2016
Finance Committee
May 19, 2016
Board of Directors
May 19, 2016
Finance Committee
Apr 21, 2016
Compensation & Human Resources Committee
Apr 21, 2016
Board of Directors
Apr 21, 2016
Planning & Administration Committee
Mar 17, 2016
Finance Committee
Mar 17, 2016
Board of Directors
Mar 17, 2016
Audit Committee
Mar 17, 2016
Planning & Administration Committee
Jan 21, 2016
Finance Committee
Jan 21, 2016
Board of Directors
Jan 21, 2016
Finance Committee
Dec 17, 2015
Board of Directors
Dec 17, 2015
Finance Committee
Dec 3, 2015
Finance Committee
Nov 19, 2015
Board of Directors
Nov 19, 2015
Planning & Administration Committee
Oct 15, 2015
Finance Committee
Oct 15, 2015
Board of Directors
Oct 15, 2015
Planning & Administration Committee (Due to technical difficulty, the video for this meeting is not available)
Sep 10, 2015
Finance Committee (Due to technical difficulty, the video for this meeting is not available)
Sep 10, 2015
Board of Directors (Due to technical difficulty, the video for this meeting is not available)
Sep 10, 2015
Planning & Administration Committee
Aug 20, 2015
Finance Committee
Aug 20, 2015
Board of Directors
Aug 20, 2015
Board of Directors
Jul 16, 2015
Planning & Administration Committee
Jun 25, 2015
Finance Committee
Jun 25, 2015
Board of Directors
Jun 25, 2015
Audit Committee
Jun 25, 2015
Finance Committee
May 21, 2015
Board of Directors
May 21, 2015
Finance Committee
Apr 16, 2015
Board of Directors
Apr 16, 2015
Planning & Administration Committee
Mar 19, 2015
Finance Committee
Mar 19, 2015
Board of Directors
Mar 19, 2015
Audit Committee
Mar 19, 2015
Planning & Administration Committee
Jan 22, 2015
Finance Committee
Jan 22, 2015
Board of Directors
Jan 22, 2015
Board of Directors
Dec 17, 2014
Finance Committee
Dec 3, 2014
Back to top


Welcome! Synergy is an interactive globe controllable through gestures captured by a LEAP Motion device and also through your voice captured by Chrome's Web Speech API. It has been developed by VanGoghsCoffee, DavidKoenig, moehlone and thoomi during the course "Digitale Medien 3" at Erfurt University of Applied Sciences.
The description of the current tutorial slide.


Something terrible happened. It is possible I am in the process of updating the database. If the problem persists email me at<EMAIL_ADDRESS>and let me know what your query was.


Resetting your Password
If you forget your password you can have it sent to the email address associated with your user account.
- Click the Login link (typically located in the top right corner of each page) - OR - Navigate to an Account Login module.
- Click the Reset Password button.
- In the User Name text box, enter your user name.
- Optional. If the Security Code field is displayed, enter the code displayed as a picture into the Security Code text box.
- Click the Send Reset Link button. If the password reset link sends successfully, the message " If the username entered was correct, you should receive a new email shortly with a link to reset your password" is displayed.


Lori Harvey Attends Future’s Birthday Party Adding To Their Dating Rumors!
by Nick MarkusWeeks after sparking dating rumors with Future, Lori Harvey was in attendance at the rapper’s birthday party, only adding more to the fans’ beliefs that they are romantically involved! As you may know, Future just turned 36 years old and had a super fun bash to which Steve Harvey’s daughter was also invited.
The model was seen having the time of her life at the party so it makes sense that more and more people are convinced the two might be dating or at least on their way to becoming a couple.
You may remember that, before being linked to Diddy, the model was, supposedly, with Future.
The 22-year-old looked stunning in a strapless dress as photos from the party prove and it also looks like the bash had a dress code – head to toe white – since everyone in attendance was rocking white clothes.
At some point, everyone is gathered around Future as he blows out the candles on his birthday cake.
Lori looks super excited as she smiles brightly while taking pics of the birthday boy.
In the photos, they are not really shown interacting but there have been other things that have gotten fans thinking they pretty much silently confirmed they are dating.
These clues are from before the bash.
Furthermore, while Lori and Future have never officially confirmed they were an item at any point, they do have a romantic history together that was on and off.
The romance rumors started at the beginning of this year but Lori was in fact linked not just to Future but also to Trey Songz, Lewis Hamilton and Justin Combs, all at the same time!
However, none was made official and in fact, the speculations about these four men went away for a while when she started to be linked to someone else – Justin’s dad – Diddy!
The two spent all summer together despite never confirming they were dating so the speculations grew stronger.
But, last month, when he was seen with another woman in Nobu, Lori not only stopped hanging out with Diddy, but even unfollowed him on social media!


Background¶
Notation¶
The following basic notation will be used throughout.
\(d\): dimension;
\(\mathfrak{X} \subset \mathbb{R}^d\): feasible domain;
\(\lambda_{\max}\): maximal eigenvalue of a positive definite matrix;
\(\| \cdot \|\): Euclidean norm of a vector in \(\mathbb{R}^d\);
\(N\): total number of starting points;
\(X = {x_1,x_2,\ldots,x_N}\): a sequence of points in \(\mathfrak{X}\);
\(x_n=x_n^{(0)} \in X\), where \(n=1,2, \ldots N\): point chosen from \({X}\);
\(x_n^{(k)}\): the \(n\)-th point after \(k\) iterations of anti-gradient descent;
\(x_n^{(K_n)}\): smallest \(k=K_n\) such that \(\| \nabla f(x_n^{(k)}) \| < \delta\);
\(f(x_n^{(k)})\): objective function at \(x_n^{(k)}\);
\(\nabla f(x_n^{(k)})\): gradient of \(f\) at \(x_n^{(k)}\);
anti-gradient descent iteration:
\(\gamma_n^{(k)}\): step size for an anti-gradient descent iteration (1). Note that \(\gamma_n^{(k)} \geq 0\);
partner point:
\(\beta\) : small positive constant used as the step size for a parnter point (2);
\(\delta\) and \(\eta\): small positive constants;
\(M\): the minimum number of anti-gradient descent iterations (1) applied at each initial point \(x_n=x_n^{(0)}\) where \(n=1,2, \ldots, N\);
\(l\): index for the local minimizers \(l=1,\ldots,L\), where \(L\) is the total number of local minimizers found so far;
\(A_l\): \(l\)-th region of attraction;
\(x_l^{(K_l)}\): \(l\)-th local minimizer.
Main Conditions of the METOD Algorithm¶
The first main condition of the METOD Algorithm tests the following condition for each \(l=1,\ldots,L\) and all \(i=M-1,\ldots,K_l\)
For a given \(l\), if condition (3) holds for all \(i=M-1,\ldots, K_l\), then it is possible \(x_n\) belongs to \(A_l\), the same region of attraction corresponding to \(x_l^{(K_l)}\), and we terminate anti-gradient descent iterations (1). Let \(S_n\) be the set of indices \(l\), such that \(x_n\) may belong to region of attraction \(A_l\). If condition (3) holds, we add index \(l\) to the set \(S_n\).
If condition (3) does not hold for a point \(x_n\) with any \(l=1,\ldots,L\), then we apply anti-gradient descent iterations (1) until a minimizer \(x_n^{(K_n)}\) is found. However, we may have that minimizer \(x_n^{(K_n)}\) has already been discovered. As a consequence, the second main condition of the algorithm is to ensure that all discovered local minimizers are unique. To return unique local minimizers only, the following condition is tested for all \(i=1,\ldots,L\) and \(j=i + 1,\ldots,L\)
If condition (4) fails for any \(j\), then minimizers \(x_i^{ (K_i)}\) and \(x_j^{(K_j)}\) are the same and \(j\) is removed from the set of indices \(l=1,\ldots,L\).
METOD Algorithm¶
The METOD Algorithm can be split into the following three parts.
Initialization
Terminate anti-gradient descent iterations for \(n\)-th point.
For \(n=2\) to \(N\)
Choose \(x_n=x_n^{(0)} \in {X}\). Compute \(x_n^{(j)}\) for \(j=1, \ldots, M\) and the associated partner points using (2).
For \(l=1\) to \(L\)
To get to this stage, \(S_n\) must be empty. Hence, let \(x_{L+1} = x_n\) and continue iterations (1) until a minimizer \(x_{L+1}^{(K_{L+1})}\) is found.
For all points \(x_{L+1}^{(k)}\) \(k =M-1, \ldots, K_{L+1}\), compute the associated partner points using (2) and set \(L \gets L+1\).
Return unique minimizers from Step 2.
For \(i=1\) to \(L\)
For \(j=i+1\) to \(L\)
If condition (4) is not satisfied for \({x}_{i}^{(K_i)}\) and \({x}_{j}^{(K_j)}\)
Remove index \(j\) from the set of indices \(l=1,\ldots,L\).
Code Structure¶
The METOD Algorithm code can be found here. The main program that executes the METOD Algorithm is metod.py and the following diagram shows the various programs that contribute to metod.py.


Karan Dudeja
👋
I'm a designer + programmer interested in computational tools for creativity.
Portfolio
LinkedIn
Twitter


We're sorry but 2048 doesn't work properly without JavaScript enabled. Please enable it to continue.


nm scale
The idea behind scaling the x-axis in nanometer is taking two spectra with one
defined maximun at a distinct frequency. These spectra are available by laserpointer.
Howto
- Take a spectrum of a e.g. 405nm laser with one peak and save it under a filename 405nm.csv
the first three numbers gives the program the frequency
- Same procedure with a longer wavelength.
- Hit the [nm]-button and follow the instructions. Something like this appears:
- To use the scale check
The checkbutton is enabled after scaling the x-axis.


P&Y 50th
☰
The Rodriquezes
(current)
Pete Rodriquez
Yvonne Rodriquez
Jeannette Rodriquez
Previous
Next