It is a non-recoverable dynamic
error if the effective value of the
name
attribute [of the xsl:namespace
instruction] is neither a zero-length string nor an
NCName
Names, or if it is
xmlns
.
It is a non-recoverable dynamic
error if the xsl:namespace
instruction generates a namespace node whose name is
xml
and whose string value is not
http://www.w3.org/XML/1998/namespace
, or a
namespace node whose string value is
http://www.w3.org/XML/1998/namespace
and
whose name is not xml
.
It is a non-recoverable dynamic
error if evaluating the select
attribute or the contained sequence constructor of an
xsl:namespace
instruction results in a zero-length string.
It is a non-recoverable dynamic
error if any undiscarded item in the atomized
sequence supplied as the value of the value
attribute of xsl:number
cannot be
converted to an integer, or if the resulting integer is
less than 0 (zero).
It is a non-recoverable dynamic
error if, for any sort key component, the set
of sort key values evaluated for
all the items in the initial sequence, after any
type conversion requested, contains a pair of ordinary
values for which the result of the XPath lt
operator is an error.
It is a non-recoverable dynamic
error if the collation
attribute of
xsl:sort
(after
resolving against the base URI) is not a URI that is
recognized by the implementation as referring to a
collation.
It is a non-recoverable dynamic
error if the collation URI specified to xsl:for-each-group
(after resolving against the base URI) is a
collation that is not recognized by the implementation.
(For notes, [see ERR XTDE1035].)
It is a non-recoverable dynamic
error if the effective value of the
regex
attribute [of the xsl:analyze-string
instruction] does not conform to the required syntax for regular expressions, as
specified in [Functions and
Operators]. If the regular expression is known
statically (for example, if the attribute does not
contain any expressions enclosed in curly
brackets) then the processor may signal the error as a static
error.
It is a non-recoverable dynamic
error if the effective value of the
flags
attribute [of the xsl:analyze-string
instruction] has a value other than the values defined in
[Functions and Operators].
If the value of the attribute is known statically (for
example, if the attribute does not contain any expressions
enclosed in curly brackets) then the processor
may signal the error as a
static
error.
It is a non-recoverable dynamic
error if the effective value of the
regex
attribute [of the xsl:analyze-string
instruction] is a regular expression that matches a
zero-length string: or more specifically, if the regular
expression $r
and flags $f
are
such that matches("", $r, $f)
returns true.
If the regular expression is known statically (for
example, if the attribute does not contain any expressions
enclosed in curly brackets) then the processor
may signal the error as a
static
error.
When a URI reference [supplied to the document
function]
contains a fragment identifier, it is a recoverable dynamic error if
the media type is not one that is recognized by the
processor, or if the fragment identifier does not conform
to the rules for fragment identifiers for that media
type, or if the fragment identifier selects something
other than a sequence of nodes (for example, if it
selects a range of characters within a text node).
Action: The optional recovery
action is to ignore the fragment identifier and
return the document node.
It is a non-recoverable dynamic
error if a URI [supplied in the first argument to the
unparsed-text
function] contains a fragment identifier, or
if it cannot be used to retrieve a resource containing
text.
It is a non-recoverable dynamic
error if a resource [retrieved using the unparsed-text
function] contains octets that cannot be decoded into
Unicode characters using the specified encoding, or if
the resulting characters are not permitted XML
characters. This includes the case where the processor does not
support the requested encoding.
It is a non-recoverable dynamic
error if the second argument of the unparsed-text
function is omitted and the processor cannot infer the encoding
using external information and the encoding is not
UTF-8.
It is a non-recoverable dynamic
error if the value [of the first argument to the
key
function] is
not a valid QName, or if there is no namespace
declaration in scope for the prefix of the QName, or if
the name obtained by expanding the QName is not the same
as the expanded name of any xsl:key
declaration in
the stylesheet. If the processor is able
to detect the error statically (for example, when the
argument is supplied as a string literal), then the
processor may optionally signal
this as a static error.
It is a non-recoverable dynamic
error to call the key
function with two
arguments if there is no context node, or if the root
of the tree containing the context node is not a document
node; or to call the function with three arguments
if the root of the tree containing the node supplied in
the third argument is not a document node.
It is a non-recoverable dynamic
error if the name specified as the
$decimal-format-name
argument [ to the
format-number
function] is not a valid QName, or if its prefix has not been
declared in an in-scope namespace declaration, or
if the stylesheet does not contain a
declaration of a decimal-format with a matching expanded-QName. If the processor
is able to detect the error statically (for example, when
the argument is supplied as a string literal), then the
processor may optionally signal
this as a static error.
The picture string [supplied to the
format-number
function] must conform to the
following rules. [ See full specification.] It is a
non-recoverable dynamic
error if the picture string does not satisfy these
rules.
It is a non-recoverable dynamic error if the syntax of the picture [used for date/time formatting] is incorrect.
It is a non-recoverable dynamic
error if a component specifier within the picture
[used for date/time formatting] refers to components that
are not available in the given type of
$value
, for example if the picture supplied
to the format-time
refers to the year, month, or day component.
If the current
function is
evaluated within an expression that is evaluated when the
context item is undefined, a non-recoverable dynamic
error occurs.
It is a non-recoverable dynamic
error if the unparsed-entity-uri
function is called when there is no context node,
or when the root of the tree containing the context node
is not a document node.
It is a non-recoverable dynamic
error if the unparsed-entity-public-id
function is called when there is no context node,
or when the root of the tree containing the context node
is not a document node.
It is a non-recoverable dynamic
error if the value [supplied as the
$property-name
argument to the system-property
function] is not a valid QName, or if there is no
namespace declaration in scope for the prefix of the
QName. If the processor is able to detect the error
statically (for example, when the argument is supplied as
a string literal), then the processor may optionally signal this as a static
error.
When a transformation is terminated by use of
xsl:message terminate="yes"
, the effect is
the same as when a non-recoverable dynamic
error occurs during the transformation.
It is a non-recoverable dynamic
error if the argument [passed to the function-available
function] does not evaluate to a string that is a valid
QName, or if there
is no namespace declaration in scope for the prefix of
the QName. If the
processor is able to detect the error statically (for
example, when the argument is supplied as a string
literal), then the processor may optionally signal this as a static
error.
It is a non-recoverable dynamic error if the arguments supplied to a call on an extension function do not satisfy the rules defined for that particular extension function, or if the extension function reports an error, or if the result of the extension function cannot be converted to an XPath value.
When backwards compatible behavior is enabled, it is a non-recoverable dynamic error to evaluate an extension function call if no implementation of the extension function is available.
It is a non-recoverable dynamic
error if the argument [passed to the type-available
function] does not evaluate to a string that is a valid
QName, or if there
is no namespace declaration in scope for the prefix of
the QName. If the
processor is able to detect the error statically (for
example, when the argument is supplied as a string
literal), then the processor may optionally signal this as a static
error.
It is a non-recoverable dynamic
error if the argument [passed to the element-available
function] does not evaluate to a string that is a valid
QName, or if there
is no namespace declaration in scope for the prefix of
the QName. If the
processor is able to detect the error statically (for
example, when the argument is supplied as a string
literal), then the processor may optionally signal this as a static
error.
When a processor performs fallback for an
extension instruction
that is not recognized, if the instruction element has
one or more xsl:fallback
children, then the content of each of the xsl:fallback
children must be evaluated; it
is a non-recoverable dynamic
error if it has no xsl:fallback
children.
It is a non-recoverable dynamic
error if the effective value of the
format
attribute [of an xsl:result-document
element] is not a valid lexical QName, or if it does not
match the expanded-QName of an output
definition in the stylesheet. If the processor is able
to detect the error statically (for example, when the
format
attribute contains no curly
brackets), then the processor may optionally signal this as a static
error.
It is a non-recoverable dynamic
error to evaluate the xsl:result-document
instruction in temporary output
state.
It is a non-recoverable dynamic error for a transformation to generate two or more final result trees with the same URI.
It is a recoverable dynamic error for a transformation to generate two or more final result trees with URIs that identify the same physical resource. The optional recovery action is implementation-dependent, since it may be impossible for the processor to detect the error.
It is a recoverable dynamic error for
a stylesheet to write to an external
resource and read from the same resource during a single
transformation, whether or not the same URI is used to
access the resource in both cases.
Action: The optional recovery
action is implementation-dependent:
implementations are not required to detect the error condition.
Note that if the error is not detected, it is
undefined whether the document that is read from the
resource reflects its state before or after the result
tree is written.
It is a recoverable dynamic error if
an xsl:value-of
or
xsl:text
instruction specifies that output escaping is to be
disabled and the implementation does not support
this.
Action: The optional recovery
action is to ignore the
disable-output-escaping
attribute.
It is a recoverable dynamic error if
an xsl:value-of
or
xsl:text
instruction specifies that output escaping is to be
disabled when writing to a final result tree that
is not being serialized.
Action: The optional recovery
action is to ignore the
disable-output-escaping
attribute.
A basic XSLT processor
must raise a non-recoverable dynamic
error if the input to the processor includes a node
with a type annotation other than
xs:untyped
or
xs:untypedAtomic
, or an atomic
value of a type other than those which a basic XSLT
processor supports.
This appendix provides a summary of XSLT language features whose effect is explicitly implementation-defined. The conformance rules (see 21 Conformance) require vendors to provide documentation that explains how these choices have been exercised.
The way in which an XSLT processor is invoked, and the way in which values are supplied for the source document, starting node, stylesheet parameters, and base output URI, are implementation-defined. (See 2.3 Initiating a Transformation)
The mechanisms for creating new extension instructions and extension functions are implementation-defined. (See 2.7 Extensibility)
Where the specification provides a choice between signaling a dynamic error or recovering, the decision that is made (but not the recovery action itself) is implementation-defined. (See 2.9 Error Handling)
It is implementation-defined whether type errors are signaled statically. (See 2.9 Error Handling)
The set of namespaces that are specially recognized by the implementation (for example, for user-defined data elements, and extension attributes) is implementation-defined. (See 3.6.2 User-defined Data Elements)
The effect of user-defined data elements whose name is in a namespace recognized by the implementation is implementation-defined. (See 3.6.2 User-defined Data Elements)
It is implementation-defined whether an XSLT 2.0 processor supports backwards-compatible behavior. (See 3.8 Backwards-Compatible Processing)
It is implementation-defined what forms of URI
reference are acceptable in the href
attribute of the xsl:include
and
xsl:import
elements, for example, the URI schemes that may be used,
the forms of fragment identifier that may be used, and
the media types that are supported. (See 3.10.1 Locating Stylesheet
Modules)
An implementation may define mechanisms, above and
beyond xsl:import-schema
that allow schema components such as type
definitions to be made available within a stylesheet.
(See 3.13 Built-in
Types)
It is implementation-defined which versions of XML and XML Namespaces (1.0 and/or 1.1) are supported. (See 4.1 XML Versions)
Limits on the value space of primitive data types, where not fixed by [XML Schema Part 2], are implementation-defined. (See 4.6 Limits)
The implicit timezone for a transformation is implementation-defined. (See <IP_ADDRESS> Other components of the XPath Dynamic Context)
If an xml:id
attribute that has not been
subjected to attribute value normalization is copied from
a source tree to a result tree, it is
implementation-defined whether attribute value
normalization will be applied during the copy process.
(See 11.9.1 Shallow
Copy)
The numbering sequences supported by the xsl:number
instructions, beyond those defined in this specification,
are implementation-defined. (See 12.3 Number to String Conversion
Attributes)
There may be
implementation-defined upper bounds on the numbers that
can be formatted by xsl:number
using any
particular numbering sequence. (See 12.3 Number to String Conversion
Attributes)
The set of languages for which numbering is supported
by xsl:number
,
and the method of choosing a default language, are
implementation-defined. (See 12.3
Number to String Conversion Attributes)
If the data-type
attribute of the
xsl:sort
element
has a value other than text
or
number
, the effect is
implementation-defined. (See 13.1.2 Comparing Sort Key
Values)
The facilities for defining collations and allocating URIs to identify them are implementation-defined. (See 13.1.3 Sorting Using Collations)
The algorithm used by xsl:sort
to locate a
collation, given the values of the lang
and
case-order
attributes, is
implementation-defined. (See 13.1.3 Sorting Using
Collations)
The set of media types recognized by the processor,
for the purpose of interpreting fragment identifiers in
URI references passed to the document
function,
is implementation-defined. (See 16.1 Multiple Source
Documents)
The set of encodings recognized by the unparsed-text
function, other than utf-8
and
utf-16
, is implementation-defined.
(See 16.2 Reading Text
Files)
If no encoding is specified on a call to the unparsed-text
function, the processor may use
implementation-defined
heuristics to determine the likely encoding. (See
16.2 Reading Text
Files)
The set of languages, calendars, and countries that are supported in the date formatting functions is implementation-defined. If any of these arguments is omitted or set to an empty sequence, the default is implementation-defined. (See 16.5.2 The Language, Calendar, and Country Arguments)
The choice of the names and abbreviations used in any given language for calendar units such as days of the week and months of the year is implementation-defined. (See 16.5.2 The Language, Calendar, and Country Arguments)
The values returned by the system-property
function, and the names of the additional properties that
are recognized, are implementation-defined. (See 16.6.5 system-property)
The destination and formatting of messages written
using the xsl:message
instruction are implementation-defined. (See 17 Messages)
The effect of an extension function returning a string containing characters that are not legal in XML is implementation-defined. (See 18.1.2 Calling Extension Functions)
The way in which external objects are represented in the type system is implementation-defined. (See 18.1.3 External Objects)
The way in which a final result tree is delivered to an application is implementation-defined. (See 19 Final Result Trees)
Implementations may provide additional mechanisms allowing users to define the way in which final result trees are processed. (See 19.1 Creating Final Result Trees)
If serialization is supported, then the location to which a final result tree is serialized is implementation-defined, subject to the constraint that relative URIs used to reference one tree from another remain valid. (See 20 Serialization)
The default value of the encoding
attribute of the xsl:output
element is
implementation-defined. (See 20 Serialization)
It is implementation-defined which versions of XML,
HTML, and XHTML are supported in the version
attribute of the xsl:output
declaration. (See 20
Serialization)
The default value of the byte-order-mark
serialization parameter is implementation-defined in the
case of UTF-8 encoding. (See 20 Serialization)
It is implementation-defined whether, and under what circumstances, disabling output escaping is supported. (See 20.2 Disabling Output Escaping)
The following schema describes the structure of an XSLT stylesheet module. It does not define all the constraints that apply to a stylesheet (for example, it does not attempt to define a data type that precisely represents attributes containing XPath expressions). However, every valid stylesheet module conforms to this schema, unless it contains elements that invoke forwards-compatible-behavior.
A copy of this schema is available at http://www.w3.org/2007/schema-for-xslt20.xsd
<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.w3.org/1999/XSL/Transform" elementFormDefault="qualified" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <xs:annotation> <xs:documentation> This is a schema for XSLT 2.0 stylesheets. It defines all the elements that appear in the XSLT namespace; it also provides hooks that allow the inclusion of user-defined literal result elements, extension instructions, and top-level data elements. The schema is derived (with kind permission) from a schema for XSLT 1.0 stylesheets produced by Asir S Vedamuthu of WebMethods Inc. This schema is available for use under the conditions of the W3C Software License published at http://www.w3.org/Consortium/Legal/copyright-software-19980720 The schema is organized as follows: PART A: definitions of complex types and model groups used as the basis for element definitions PART B: definitions of individual XSLT elements PART C: definitions for literal result elements PART D: definitions of simple types used in attribute definitions This schema does not attempt to define all the constraints that apply to a valid XSLT 2.0 stylesheet module. It is the intention that all valid stylesheet modules should conform to this schema; however, the schema is non-normative and in the event of any conflict, the text of the Recommendation takes precedence. This schema does not implement the special rules that apply when a stylesheet has sections that use forwards-compatible-mode. In this mode, setting version="3.0" allows elements from the XSLT namespace to be used that are not defined in XSLT 2.0. Simplified stylesheets (those with a literal result element as the outermost element) will validate against this schema only if validation starts in lax mode. This version is dated 2005-02-11 Authors: Michael H Kay, Saxonica Limited Jeni Tennison, Jeni Tennison Consulting Ltd. </xs:documentation> </xs:annotation> <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <!-- The declaration of xml:space and xml:lang may need to be commented out because of problems processing the schema using various tools --> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/> <!--  (a) do nothing. This allows any element to be used as a literal result element, provided it is not in the XSLT namespace (b) declare all permitted literal result elements as members of the xsl:literal-result-element substitution group (c) redefine the model group xsl:result-elements to accommodate all permitted literal result elements. Literal result elements are allowed to take certain attributes in the XSLT namespace. These are defined in the attribute group literal-result-element-attributes, which can be included in the definition of any literal result element. </xs:documentation> </xs:annotation> <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <xs:element name="literal-result-element" abstract="true" type="xs:anyType"/> <xs:attributeGroup name="literal-result-element-attributes"> <xs:attribute name="default-collation" form="qualified" type="xsl:uri-list"/> <xs:attribute name="extension-element-prefixes" form="qualified" type="xsl:prefixes"/> <xs:attribute name="exclude-result-prefixes" form="qualified" type="xsl:prefixes"/> <xs:attribute name="xpath-default-namespace" form="qualified" type="xs:anyURI"/> <xs:attribute name="inherit-namespaces" form="qualified" type="xsl:yes-or-no" default="yes"/> <xs:attribute name="use-attribute-sets" form="qualified" type="xsl:QNames" default=""/> <xs:attribute name="use-when" form="qualified" type="xsl:expression"/> <xs:attribute name="version" form="qualified" type="xs:decimal"/> <xs:attribute name="type" form="qualified" type="xsl:QName"/> <xs:attribute name="validation" form="qualified" type="xsl:validation-type"/> </xs:attributeGroup> <xs:group name="result-elements"> <xs:choice> <xs:element ref="xsl:literal-result-element"/> <xs:any namespace="##other" processContents="lax"/> <xs:any namespace="##local" processContents="lax"/> </xs:choice> </xs:group> <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <xs:annotation> <xs:documentation> PART D: definitions of simple types used in stylesheet attributes </xs:documentation> </xs:annotation> <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <xs:simpleType name="avt"> <xs:annotation> <xs:documentation> This type is used for all attributes that allow an attribute value template. The general rules for the syntax of attribute value templates, and the specific rules for each such attribute, are described in the XSLT 2.0 Recommendation. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType> <xs:simpleType name="char"> <xs:annotation> <xs:documentation> A string containing exactly one character. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:length value="1"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="expression"> <xs:annotation> <xs:documentation> An XPath 2.0 expression. </xs:documentation> </xs:annotation> <xs:restriction base="xs:token"> <xs:pattern value=".+"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="input-type-annotations-type"> <xs:annotation> <xs:documentation> Describes how type annotations in source documents are handled. </xs:documentation> </xs:annotation> <xs:restriction base="xs:token"> <xs:enumeration value="preserve"/> <xs:enumeration value="strip"/> <xs:enumeration value="unspecified"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="level"> <xs:annotation> <xs:documentation> The level attribute of xsl:number: one of single, multiple, or any. </xs:documentation> </xs:annotation> <xs:restriction base="xs:NCName"> <xs:enumeration value="single"/> <xs:enumeration value="multiple"/> <xs:enumeration value="any"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="mode"> <xs:annotation> <xs:documentation> The mode attribute of xsl:apply-templates: either a QName, or #current, or #default. </xs:documentation> </xs:annotation> <xs:union memberTypes="xsl:QName"> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="#default"/> <xs:enumeration value="#current"/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType> <xs:simpleType name="modes"> <xs:annotation> <xs:documentation> The mode attribute of xsl:template: either a list, each member being either a QName or #default; or the value #all </xs:documentation> </xs:annotation> <xs:union> <xs:simpleType> <xs:list> <xs:simpleType> <xs:union memberTypes="xsl:QName"> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="#default"/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType> </xs:list> </xs:simpleType> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="#all"/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType> <xs:simpleType name="nametests"> <xs:annotation> <xs:documentation> A list of NameTests, as defined in the XPath 2.0 Recommendation. Each NameTest is either a QName, or "*", or "prefix:*", or "*:localname" </xs:documentation> </xs:annotation> <xs:list> <xs:simpleType> <xs:union memberTypes="xsl:QName"> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="*"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:restriction base="xs:token"> <xs:pattern value="\i\c*:\*"/> <xs:pattern value="\*:\i\c*"/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType> </xs:list> </xs:simpleType> <xs:simpleType name="prefixes"> <xs:list itemType="xs:NCName"/> </xs:simpleType> <xs:simpleType name="prefix-list-or-all"> <xs:union memberTypes="xsl:prefix-list"> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="#all"/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType> <xs:simpleType name="prefix-list"> <xs:list itemType="xsl:prefix-or-default"/> </xs:simpleType> <xs:simpleType name="method"> <xs:annotation> <xs:documentation> The method attribute of xsl:output: Either one of the recognized names "xml", "xhtml", "html", "text", or a QName that must include a prefix. </xs:documentation> </xs:annotation> <xs:union> <xs:simpleType> <xs:restriction base="xs:NCName"> <xs:enumeration value="xml"/> <xs:enumeration value="xhtml"/> <xs:enumeration value="html"/> <xs:enumeration value="text"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:restriction base="xsl:QName"> <xs:pattern value="\c*:\c*"/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType> <xs:simpleType name="pattern"> <xs:annotation> <xs:documentation> A match pattern as defined in the XSLT 2.0 Recommendation. The syntax for patterns is a restricted form of the syntax for XPath 2.0 expressions. </xs:documentation> </xs:annotation> <xs:restriction base="xsl:expression"/> </xs:simpleType> <xs:simpleType name="prefix-or-default"> <xs:annotation> <xs:documentation> Either a namespace prefix, or #default. Used in the xsl:namespace-alias element. </xs:documentation> </xs:annotation> <xs:union memberTypes="xs:NCName"> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="#default"/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType> <xs:simpleType name="QNames"> <xs:annotation> <xs:documentation> A list of QNames. Used in the [xsl:]use-attribute-sets attribute of various elements, and in the cdata-section-elements attribute of xsl:output </xs:documentation> </xs:annotation> <xs:list itemType="xsl:QName"/> </xs:simpleType> <xs:simpleType name="QName"> <xs:annotation> <xs:documentation> A QName. This schema does not use the built-in type xs:QName, but rather defines its own QName type. Although xs:QName would define the correct validation on these attributes, a schema processor would expand unprefixed QNames incorrectly when constructing the PSVI, because (as defined in XML Schema errata) an unprefixed xs:QName is assumed to be in the default namespace, which is not the correct assumption for XSLT. The data type is defined as a restriction of the built-in type Name, restricted so that it can only contain one colon which must not be the first or last character. </xs:documentation> </xs:annotation> <xs:restriction base="xs:Name"> <xs:pattern value="([^:]+:)?[^:]+"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="sequence-type"> <xs:annotation> <xs:documentation> The description of a data type, conforming to the SequenceType production defined in the XPath 2.0 Recommendation </xs:documentation> </xs:annotation> <xs:restriction base="xs:token"> <xs:pattern value=".+"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="uri-list"> <xs:list itemType="xs:anyURI"/> </xs:simpleType> <xs:simpleType name="validation-strip-or-preserve"> <xs:annotation> <xs:documentation> Describes different ways of type-annotating an element or attribute. </xs:documentation> </xs:annotation> <xs:restriction base="xsl:validation-type"> <xs:enumeration value="preserve"/> <xs:enumeration value="strip"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="validation-type"> <xs:annotation> <xs:documentation> Describes different ways of type-annotating an element or attribute. </xs:documentation> </xs:annotation> <xs:restriction base="xs:token"> <xs:enumeration value="strict"/> <xs:enumeration value="lax"/> <xs:enumeration value="preserve"/> <xs:enumeration value="strip"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="yes-or-no"> <xs:annotation> <xs:documentation> One of the values "yes" or "no". </xs:documentation> </xs:annotation> <xs:restriction base="xs:token"> <xs:enumeration value="yes"/> <xs:enumeration value="no"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="yes-or-no-or-omit"> <xs:annotation> <xs:documentation> One of the values "yes" or "no" or "omit". </xs:documentation> </xs:annotation> <xs:restriction base="xs:token"> <xs:enumeration value="yes"/> <xs:enumeration value="no"/> <xs:enumeration value="omit"/> </xs:restriction> </xs:simpleType> </xs:schema>
This specification was developed and approved for publication by the W3C XSL Working Group (WG). WG approval of this specification does not necessarily imply that all WG members voted for its approval.
The chair of the XSL WG is Sharon Adler, IBM. The XSL Working Group includes two overlapping teams working on XSLT and XSL Formatting Objects. The members of the XSL WG currently engaged in XSLT activities are:
| Participant | Affiliation |
|---|---|
| Colin Paul Adams | Invited Expert |
| Anders Berglund | IBM |
| Scott Boag | IBM |
| Michael Kay | Invited Expert |
| Alex Milowski | Invited Expert |
| William Peterson | Novell, Inc |
| Michael Sperberg-McQueen | W3C |
| Zarella Rendon | Invited Expert |
| Jeni Tennison | Invited Expert |
| Joanne Tong | IBM |
| Norm Walsh | Sun Microsystems Inc. |
| Mohamed Zergaoui | Innovimax SARL |
| (vacancy) | Oracle |
Alternates are listed only where they have taken an active part in working group discussions. However, the group acknowledges the support that many members receive from colleagues in their organizations, whether or not they are officially appointed as alternates.
The W3C representative on the XSL Working Group is Michael Sperberg-McQueen.
The following individuals made significant contributions to XSLT 2.0 while they were members of the Working Group, and in some cases afterwards:
James Clark, Invited Expert
Jonathan Marsh, Microsoft
Steve Muench, Oracle
Steve Zilles, Adobe
Evan Lenz, XYZFind
Mark Scardina, Oracle
Kristoffer Rose, IBM
Henry Zongaro, IBM
Henry Thompson, University of Edinburgh
K Karun, Oracle
The working group wishes to acknowledge the contribution
made by David Marston of IBM especially to the new
specification of the format-number
function.
This specification builds on the success of the XSLT 1.0 Recommendation. For a list of contributors to XSLT 1.0, see [XSLT 1.0].
This section provides a checklist of progress against the published XSLT 2.0 Requirements document (see [XSLT 2.0 Requirements]).
Requirement 1
must Maintain Backwards Compatibility with XSLT 1.1 [Read this as "with XSLT 1.0"]
Any stylesheet whose behavior is fully defined in XSLT 1.0 and which generates no errors will produce the same result tree under XSLT 2.0
Response
Requirement 2
must Match Elements with Null Values
A stylesheet should be able to match elements and attributes whose value is explicitly null.
Response
This has been handled as an XPath 2.0 requirement. A
new function nilled
FO is available to test whether an
element has been marked as nil after schema
validation.
Requirement 3
should Allow Included Documents to "Encapsulate" Local Stylesheets
XSLT 2.0 should define a mechanism to allow the templates in a stylesheet associated with a secondary source document, to be imported and used to format the included fragment, taking precedence over any applicable templates in the current stylesheet.
Response
The facility to define modes has been generalized, making it easier to define a distinct set of template rules for processing a particular document.
Requirement 4
Could Support Accessing Infoset Items for XML Declaration
A stylesheet COULD be able to access information like the version and encoding from the XML declaration of a document.
Response
No new facilities have been provided in this area, because this information is not available in the data model.
Requirement 5
Could Provide QName Aware String Functions
Users manipulating documents (for example stylesheets, schemas) that have QName-valued element or attribute content need functions that take a string containing a QName as their argument, convert it to an expanded-QName using either the namespace declarations in scope at that point in the stylesheet, or the namespace declarations in scope for a specific source node, and return properties of the expanded-QName such as its namespace URI and local name.
Response
Functions operating on QNames are included in the XPath 2.0 Functions and Operators document: see [Functions and Operators].
Requirement 6
Could Enable Constructing a Namespace with Computed Name
Provide an xsl:namespace
analog to
xsl:element
for
constructing a namespace node with a computed prefix and
URI.
Response
An xsl:namespace
instruction has been added: see 11.7 Creating Namespace
Nodes.
Requirement 7
Could Simplify Resolving Prefix Conflicts in QName-Valued Attributes
XSLT 2.0 could simplify the renaming of conflicting namespace prefixes in result tree fragments, particularly for attributes declared in a schema as being QNames. Once the processor knows an attribute value is a QName, an XSLT processor should be able to rename prefixes and generate namespace declarations to preserve the semantics of that attribute value, just as it does for attribute names.
Response
If an attribute is typed as a QName in the schema, the new XPath 2.0 functions can be used to manipulate it as required at application level. This is considered sufficient to meet the requirement.
Requirement 8
Could Support XHTML Output Method
Complementing the existing output methods for html, xml, and text, an xhtml output method could be provided to simplify transformations which target XHTML output.
Response
An XHTML output method is now provided: see [XSLT and XQuery Serialization]
Requirement 9
must Allow Matching on Default Namespace Without Explicit Prefix
Many users stumble trying to match an element with a default namespace.
Response
A new [xsl:]xpath-default-namespace
attribute
is provided for this purpose: see 5.2 Unprefixed QNames in Expressions
and Patterns
Requirement 10
must Add Date Formatting Functions
One of the more frequent requests from XSLT 1.0 users is the ability to format date information with similar control to XSLT's format-number. XML Schema introduces several kinds of date and time datatypes which will further increase the demand for date formatting during transformations. Functionality similar to that provided by java.text.SimpleDateFormat. A date analog of XSLT's named xsl:decimal-format may be required to handle locale-specific date formatting issues.
Response
A set of date formatting functions has been specified: see 16.5 Formatting Dates and Times
Requirement 11
must Simplify Accessing Id's and Key's in Other Documents
Currently it is cumbersome to lookup nodes by id() or key() in documents other than the source document. Users must first use an xsl:for-each instruction, selecting the desired document() to make it the current node, then relative XPath expressions within the scope of the xsl:for-each can refer to id() or key() as desired.
Response
The requirement is met by the generalization of path
syntax in XPath 2.0. It is now possible to use a path
expression such as
document('a.xml')/id('A001')
.
Requirement 12
should Provide Function to Absolutize Relative URIs
There should be a way in XSLT 2.0 to create an absolute URI. The functionality should allow passing a node-set and return a string value representing the absolute URI resolved with respect to the base URI of the current node.
Response
A function
resolve-uri
FO is now
defined in [Functions and
Operators].
Requirement 13
should Include Unparsed Text from an External Resource
Frequently stylesheets must import text from external resources. Today users have to resort to extension functions to accomplish this because XSLT 1.0 only provides the document() function which, while useful, can only read external resources that are well-formed XML documents.
Response
A function unparsed-text
has
been added: see 16.2 Reading Text
Files
Requirement 14
should Allow Authoring Extension Functions in XSLT
As part of the XSLT 1.1 work done on extension functions, a proposal to author XSLT extension functions in XSLT itself was deferred for reconsideration in XSLT 2.0. This would allow the functions in an extension namespace to be implemented in "pure" XSLT, without resulting to external programming languages.
Response
A solution to this requirement, the xsl:function
element, is
included in this specification. See 10.3 Stylesheet
Functions.
Requirement 15
should Output Character Entity References Instead of Numeric Character Entities
Users have frequently requested the ability to have the output of their transformation use (named) character references instead of the numeric character entity. The ability to control this preference as the level of the whole document is sufficient. For example, rather than seeing   in the output, the user could request to see the equivalent instead.
Response
The serialization specification gives the implementation
discretion on how special characters are output. A user who
wishes to force the use of named character references can
achieve this using the new xsl:character-map
declaration.
Requirement 16
should Construct Entity Reference by Name
Analogous to the ability to create elements and attributes, users have expressed a desire to construct named entity references.
Response
No solution has been provided to this requirement; it is difficult, because entity references are not defined in the data model.
Requirement 17
should Support for Unicode String Normalization
For reliable string comparison of Unicode strings, users need the ability to apply Unicode normalization before comparing the strings.
Response
This requirement has been addressed by the provision of
the
normalize-unicode
FO
function described in [Functions
and Operators]. In addition, a serialization parameter
normalization-form
has been added.
Requirement 18
should Standardize Extension Element Language Bindings
XSLT 1.1 undertook the standardization of language bindings for XSLT extension functions. For XSLT 2.0, analogous bindings should be provided for extension elements [now renamed extension instructions].
Response
The XSL Working Group has decided not to pursue this requirement, and the attempt to standardize language bindings for extension functions that appeared in the XSLT 1.1 Working Draft has now been withdrawn. The Working Group decided that language bindings would be better published separately from the core XSLT specification.
Requirement 19
Could Improve Efficiency of Transformations on Large Documents
Many useful transformations take place on large documents consisting of thousands of repeating "sub-documents". Today transformations over these documents are impractical due to the need to have the entire source tree in memory. Enabling "progressive" transformations, where the processor is able to produce progressively more output as more input is received, is tantamount to avoiding the need for XSLT processors to have random access to the entire source document. This might be accomplished by:
Identifying a core subset of XPath that does not require random access to the source tree, or
Consider a "transform all subtrees" mode where the stylesheet says, "Apply the transformation implied by this stylesheet to each node that matches XXX, considered as the root of a separate tree, and copy all the results of these mini-transformations as separate subtrees on to the final result tree."
Response
The Working Group observes that implementation techniques for XSLT processing have advanced considerably since this requirement was written, and that further research developing new approaches continues both in industry and academia. In the light of these developments, the Working Group has decided that it would be inappropriate at this stage to identify language features or subsets designed specifically to enable progressive transformations.
Requirement 20
Could Support Reverse IDREF attributes
Given a particular value of an ID, produce a list of all elements that have an IDREF or IDREFS attribute which refers to this ID.
This functionality can be accomplished using the current <xsl:key> and key() mechanism.
Response
The idref
FO function defined in [Functions and Operators] has been
introduced in response to this requirement.
Requirement 21
Could Support Case-Insensitive Comparisons
XSLT 2.0 could expand its comparison functionality to include support for case-insensitive string comparison.
Response
This is an XPath 2.0 requirement. XPath 2.0 includes functions to convert strings to uppercase or lowercase, it also includes functions to compare strings using a named collating sequence, which provides the option of using a collating sequence that treats uppercase and lowercase as equal.
Requirement 22
Could Support Lexigraphic String Comparisons
We don't let users compare strings like $x > 'a'.
Response
This requirement has been addressed in XPath 2.0.
Requirement 23
Could Allow Comparing Nodes Based on Document Order
Support the ability to test whether one node comes before another in document order.
Response
This requirement has been addressed in XPath 2.0, using
the operators <<
and
>>
.
Requirement 24
Could Improve Support for Unparsed Entities
In XSLT 1.0 there is an asymmetry in support for unparsed entities. They can be handled on input but not on output. In particular, there is no way to do an identity transformation that preserves them. At a minimum we need the ability to retrieve the Public ID of an unparsed entity.
Response
A function to retrieve the public identifier of an unparsed entity has been added. However, no facilities have been provided to include unparsed entities in a result document.
Requirement 25
Could Allow Processing a Node with the "Next Best Matching" Template
In the construction of large stylesheets for complex
documents, it is often necessary to construct templates that
implement special behavior for a particular instance of an
element, and then apply the normal styling for that element.
Currently this is not possible because xsl:apply-templates
specifies that for any given node only a single template will
be selected and instantiated.
Currently the processor determines a list of matching
templates and then discards all but the one with the highest
priority. In order to support this requirement, the processor
would retain the list of matching templates sorted in
priority order. A new instruction, for example xsl:next-match
, in a
template would simply trigger the next template in the list
of matching templates. This "next best match" recursion
naturally bottoms out at the builtin template which can be
seen as the lowest priority matching template for every match
pattern.
Response
An xsl:next-match
instruction has been added.
Requirement 26
Could Make Coercions Symmetric By Allowing Scalar to Nodeset Conversion
Presently, no datatype can be coerced or cast to a node-set. By allowing a string value to convert to a node-set, some user "gotchas" could be avoided.
Response
The availability of sequences of strings or numbers probably meets most of the use-cases envisaged by this requirement.
Requirement 27
must Simplify Constructing and Copying Typed Content
It must be possible to construct XML Schema-typed elements and attributes. In addition, when copying an element or an attribute to the result, it should be possible to preserve the type during the process.
Response
Facilities to validate constructed and copied element and attribute nodes are defined in this specification; these elements and attributes will carry a type annotation indicating their XML Schema type. In addition, it is possible to specify when copying nodes whether type annotations should be preserved or removed.
Requirement 28
must Support Sorting Nodes Based on XML Schema Type
XSLT 1.0 supports sorting based on string-valued and number-valued expressions. XML Schema: Datatypes introduces new scalar types (for example, date) with well-known sort orders. It must be possible to sort based on these extended set of scalar data types. Since XML Schema: Datatypes does not define an ordering for complex types, this sorting support should only be considered for simple types.
should be consistent with whatever we define for the matrix of conversion and comparisons.
Response
Sorting based on any schema-defined primitive data type with a total ordering is included in this specification.
Requirement 29
Could Support Scientific Notation in Number Formatting
Several users have requested the ability to have the existing format-number() function extended to format numbers using Scientific Notation.
Response
Simple scientific formatting is now available through
support for the schema-defined xs:float
and
xs:double
data types; casting a large or small
value of these types to a string produces a representation of
the value in scientific notation. The Working Group believes
that this will meet the requirement in most cases, and has
therefore decided not to enhance the format-number
further to introduce scientific notation. Users with more
specialized requirements can write their own functions.
Requirement 30
Could Provide Ability to Detect Whether "Rich" Schema Information is Available
A stylesheet that requires XML Schema type-related
functionality could be able to test whether a "rich"
Post-Schema-Validated Infoset is available from the XML
Schema processor, so that the stylesheet can provide fallback
behavior or choose to exit with xsl:message
abort="yes"
.
Response
This requirement is satisified through the instance
of
operator in XPath 2.0, which allows expressions to
determine the type of element and attribute nodes, using
information from the schema. The details of how these
expressions behave when there is no schema are defined in the
XPath specifications.
Requirement 31
must Simplify Grouping
Grouping is complicated in XSLT 1.0. It must be possible for users to group nodes in a document based on common string-values, common names, or common values for any other expression
In addition XSLT must allow grouping based on sequential position, for example selecting groups of adjacent <P> elements. Ideally it should also make it easier to do fixed-size grouping as well, for example groups of three adjacent nodes, for laying out data in multiple columns. For each group of nodes identified, it must be possible to instantiate a template for the group. Grouping must be "nestable" to multiple levels so that groups of distinct nodes can be identified, then from among the distinct groups selected, further sub-grouping of distinct node in the current group can be done.
Response
A new xsl:for-each-group
instruction is provided: see 14
Grouping. In addition, many of the new functions and
operators provided in XPath 2.0 make these algorithms easier
to write.
This section lists all known cases where a stylesheet that was valid (produced no errors) under XSLT 1.0, and whose behavior was fully specified by XSLT 1.0, will produce different results under XSLT 2.0.
Most of the discussion is concerned with compatibility in the absence of a schema: that is, it is assumed that the source document being transformed has no schema when processed using XSLT 1.0, and that no schema is added when moving to XSLT 2.0. Some additional factors that come into play when a schema is added are noted at the end of the section.
Both in XSLT 1.0 and in XSLT 2.0, the XSLT specification places no constraints on the way in which source trees are constructed. For XSLT 2.0, however, the [Data Model] specification describes explicit processes for constructing a tree from an Infoset or a PSVI, while also permitting other processes to be used. The process described in [Data Model] has the effect of stripping whitespace text nodes from elements declared to have element-only content. Although the XSLT 1.0 specification did not preclude such behavior, it differs from the way that most existing XSLT 1.0 implementations work. It is recommended that an XSLT 2.0 implementation wishing to provide maximum interoperability and backwards compatibility should offer the user the option either to construct source trees using the processes described in [Data Model], or alternatively to retain or remove whitespace according to the common practice of previous XSLT 1.0 implementations.
To write transformations that give the same result regardless of the whitespace stripping applied during tree construction, stylesheet authors can:
use the xsl:strip-space
declaration to remove whitespace text
nodes from elements having element-only content
(this has no effect if the whitespace has already
been stripped)
use instructions such as
<xsl:apply-templates select="*"/>
that cause only the element children of the context
node to be processed, and not its text nodes.
The specification of the output of serialization is more
prescriptive than in XSLT 1.0. For example, the
html
output method is required to detect invalid HTML characters.
Also, certain combinations of serialization parameters
are now defined to be errors. Furthermore, XSLT 1.0
implementations were allowed to add additional xsl:output
attributes
that modified the behavior of the serializer. Some such
extensions might be non-conformant under the stricter
rules of XSLT 2.0. For example, some XSLT 1.0 processors
provided an extension attribute to switch off the
creation of meta
elements by the
html
output method (a facility that is now
provided as standard). A conformant XSLT 2.0 processor is
not allowed to provide such extensions.
Where necessary, implementations may provide additional serialization methods designed to mimic more closely the behavior of specific XSLT 1.0 serializers.
Some XSLT constructs behave differently under XSLT 2.0
depending on whether backwards compatible
behavior is enabled. In these cases, the behavior may
be made compatible with XSLT 1.0 by ensuring that
backwards compatible
behavior is enabled (which is done using the
[xsl:]version
attribute).
These constructs are as follows:
If the xsl:value-of
instruction has no separator
attribute,
and the value of the select
expression
is a sequence of more than one item, then under XSLT
2.0 all items in the sequence will be output, space
separated, while in XSLT 1.0, all items after the
first will be discarded.
If the effective value of an attribute value template is a sequence of more than one item, then under XSLT 2.0 all items in the sequence will be output, space separated, while in XSLT 1.0, all items after the first will be discarded.
If the expression in the value
attribute of the xsl:number
instruction returns a sequence of more than one item,
then under XSLT 2.0 all items in the sequence will be
output, as defined by the format
attribute, but under XSLT 1.0, all items after the
first will be discarded. If the sequence is empty,
then under XSLT 2.0 nothing will be output (other
than a prefix and suffix if requested), but under
XSLT 1.0, the output is "NaN". If the first item in
the sequence cannot be converted to a number, then
XSLT 2.0 signals a non-recoverable error, while XSLT
1.0 outputs "NaN".
If the expression in the value
attribute of xsl:number
returns
an empty sequence or a sequence including non-numeric
values, an XSLT 2.0 processor may signal a
recoverable error; but with backwards compatibility
enabled, it outputs NaN
.
If the atomized value of the
select
attribute of the xsl:sort
element is
a sequence of more than one item, then under XSLT 2.0
an error will be signaled, while in XSLT 1.0, all
items after the first will be discarded.
If an xsl:call-template
instruction supplies a parameter that does not
correspond to any template parameter in
the template being called, then under XSLT 2.0 a
static error is signaled, but
under XSLT 1.0 the extra parameter is ignored.
It is normally a static error if an XPath expression contains a call to an unknown function. But when backwards compatible behavior is enabled, this is a non-recoverable dynamic error, which occurs only if the function call is actually evaluated.
An XSLT 1.0 processor compared the value of the
expression in the use
attribute of
xsl:key
to
the value supplied in the second argument of the
key
function
by converting both to strings. An XSLT 2.0 processor
normally compares the values as supplied. The XSLT
1.0 behavior is retained if any of the xsl:key
elements
making up the key
definition enables backwards-compatible behavior.
If no output method is explicitly requested, and the first element node output appears to be an XHTML document element, then under XSLT 2.0 the output method defaults to XHTML; with backwards compatibility enabled, the XML output method will be used.
Backwards compatible behavior also affects the results of certain XPath expressions, as defined in [XPath 2.0].
If the source documents supplied as input to a transformation contain no type information generated from a schema then the known areas of incompatibility are as follows. These apply whether or not backwards compatible behavior is enabled.
A stylesheet that specifies a version number other than 1.0 was defined in XSLT 1.0 to execute in forwards-compatible mode; if such a stylesheet uses features that are not defined in XSLT 2.0 then errors may be signaled by an XSLT 2.0 processor that would not be signaled by an XSLT 1.0 processor.
At XSLT 1.0 the system-property
function, when called with a first argument of
"xsl:version"
, returned 1.0 as a number.
At XSLT 2.0 it returns "2.0" as a string. The
recommended way of testing
this property is, for example, <xsl:if
test="number(system-property('xsl:version')) <
2.0">
, which will work with either an XSLT
1.0 or an XSLT 2.0 processor.
At XSLT 2.0 it is an error to specify the
mode
or priority
attribute
on an xsl:template
element having no match
attribute. At
XSLT 1.0 the attributes were silently ignored in this
situation.
When an xsl:apply-templates
or xsl:apply-imports
instruction causes a built-in template rule to be
invoked, then any parameters that are supplied are
automatically passed on to any further template
rules. This did not happen in XSLT 1.0.
In XSLT 1.0 it was a recoverable error to create any node other than a text node while constructing the value of an attribute, comment, or processing-instruction; the recovery action was to ignore the offending node and its content. In XSLT 2.0 this is no longer an error, and the specified action is to atomize the node. An XSLT 2.0 processor will therefore not produce the same results as an XSLT 1.0 processor that took the error recovery action.
XSLT 1.0 defined a number of recoverable error conditions which in XSLT 2.0 have become non-recoverable errors. Under XSLT 1.0, a stylesheet that triggered such errors would fail under some XSLT processors and succeed (or at any rate, continue to completion) under others. Under XSLT 2.0 such a stylesheet will fail under all processors. Notable examples of such errors are constructing an element or attribute with an invalid name, generating attributes as children of a document node, and generating an attribute of an element after generating one or more children for the element. This change has been made in the interests of interoperability. In classifying such errors as non-recoverable, the Working Group used the criterion that no stylesheet author would be likely to write code that deliberately triggered the error and relied on the recovery action.
In XSLT 1.0, the semantics of tree construction were described as being top-down, in XSLT 2.0 they are described bottom up. In nearly all cases the end result is the same. One difference arises in the case of a tree that is constructed to contain an attribute node within a document node within an element node, using an instruction such as the following:
<xsl:template match="/"> <e> <xsl:copy> <xsl:attribute name="a">5</xsl:attribute> </xsl:copy> </e> </xsl:template>
In XSLT 1.0, the xsl:copy
did
nothing, and the attribute a
was then
attached to the element e
. In XSLT 2.0,
an error occurs when attaching the attribute
a
to the document node constructed by
xsl:copy
,
because this happens before the resulting document
node is copied to the content of the constructed
element.
In XSLT 1.0 it was not an error for the
namespace
attribute of xsl:element
or
xsl:attribute
to evaluate to an invalid URI. Since many XML parsers
accept any string as a namespace name, this rarely
caused problems. The [Data
Model], however, requires the name of a node to
be an xs:QName
, and the namespace part
of an xs:QName
is always an
xs:anyURI
. It is therefore now defined
to be an error to create an element or attribute node
in a namespace whose name is not a valid instance of
xs:anyURI
. In practice, however,
implementations have some flexibility in how
rigorously they validate namespace URIs.
It is now a static error for the stylesheet to
contain two conflicting xsl:namespace-alias
declarations with the same import precedence.
It is now a static error for an xsl:number
instruction to contain both a value
attribute and a level
,
from
, or count
attribute.
In XSLT 1.0 the value
attribute took
precedence and the other attributes were silently
ignored.
When the data-type
attribute of
xsl:sort
has
the value number
, an XSLT 1.0 processor
would evaluate the sort key as a string, and convert
the result to a number. An XSLT 2.0 processor
evaluates the sort key as a number directly. This
only affects the outcome in cases where in XSLT
1.0, conversion of a number to a string and
then back to a number does not produce the original
number, as is the case for example with the number
positive infinity.
When the data-type
attribute of
xsl:sort
is
omitted, an XSLT 1.0 processor would convert the sort
key values to strings, and sort them as strings. An
XSLT 2.0 processor will sort them according to their
actual dynamic type. This means, for example, that if
the sort key component specifies <xsl:sort
select="string-length(.)"/>
, an XSLT 2.0
processor will do a numeric sort where an XSLT 1.0
processor would have done an alphabetic sort.
When the data-type
attribute of
xsl:sort
is
omitted or has the value "text", an XSLT 1.0
processor treats a sort key whose value is an empty
node-set as being equal to a sort key whose value is
a zero-length string. XSLT 2.0 sorts the empty
sequence before the zero-length string. This means
that if there are two sort keys, say
<xsl:sort select="@a"/>
and
<xsl:sort select="@b"/>
, then an
XSLT 1.0 processor will sort the element <x
b="2"/>
after <x a=""
b="1"/>
, while an XSLT 2.0 processor will
produce the opposite ordering.
The specification of the format-number
function has been rewritten to remove the normative
dependency on the Java JDK 1.1 specification. The JDK
1.1 specification left aspects of the behavior
undefined; it is therefore likely that some cases
will give different results.
The ability to include literal text in the format
picture enclosed in single quotes has been removed;
any stylesheet that uses this feature will need to be
modified, for example to display the literal text
using the
concat
FO
function instead.
One specific difference between the XSLT 2.0 specification and a JDK-based implementation is in the handling of the negative sub-picture. JDK releases subsequent to JDK 1.1 have added the provision: If there is an explicit negative subpattern [sub-picture], it serves only to specify the negative prefix and suffix; the number of digits, minimal digits, and other characteristics are all the same as the positive pattern [sub-picture]. This statement was not present in the JDK 1.1 specification, and therefore it is not necessarily how every XSLT 1.0 implementation will behave, but it does describe the behavior of some XSLT 1.0 implementations that use the JDK directly. This behavior is not correct in XSLT 2.0: the negative sub-picture must be used as written when the number is negative.
The recovery action has changed for the error
condition where the processor cannot handle the
fragment identifier in a URI passed as an argument to
the document
function. XSLT 1.0 specified that the entire URI
reference should be ignored. XSLT 2.0 specifies that
the fragment identifier should be ignored.
XSLT 1.0 allowed the URI returned by the unparsed-entity-uri
function to be derived from some combination of the
system identifier and the public identifier in the
source XML. XSLT 2.0 returns the system identifier as
defined in the Infoset, resolved using the base URI
of the source document. A new function is provided to
return the public identifier.
The default priority of the pattern
match="/"
has changed from +0.5 to -0.5.
The effect of this is that if there are any template
rules that specify match="/"
with an
explicit user-specified priority between -0.5 and
+0.5, these will now be chosen in preference to a
template rule that specifies match="/"
with no explicit priority; previously such rules
would never have been invoked.
In XSLT 1.0 it was possible to create a processing instruction in the result tree whose string value contained a leading space. However, such leading spaces would be lost after serialization and parsing. In XSLT 2.0, any leading spaces in the string value of the processing instruction are removed at the time the node is created.
At XSLT 1.0 there were no restrictions on the namespaces that could be used for the names of user-defined stylesheet objects such as keys, variables, and named templates. In XSLT 2.0, certain namespaces (for example the XSLT namespace and the XML Schema namespace) are reserved.
An erratum to XSLT 1.0 specified what has become
known as "sticky disable-output-escaping":
specifically, that it should be possible to use
disable-output-escaping
when writing a
node to a temporary tree, and that this information
would be retained for use when the same node was
later copied to a final result tree and serialized.
XSLT 2.0 no longer specifies this behavior (though it
permits it, at the discretion of the implementation).
The use cases for this facility have been satisfied
by a completely different mechanism, the concept of
character maps (see 20.1
Character Maps).
An XSLT 1.0 processor ignored all information about
data types that might be obtained from a schema
associated with a source document. An XSLT 2.0 processor
will take account of such information, unless the
input-type-annotations
attribute is set to
strip
. This may lead to a number of
differences in behavior. This section attempts only to
give some examples of the kind of differences that might
be expected when schema information is made
available:
Operations such as sorting will be sensitive to
the data type of the items being sorted. For example,
if the data type of a sort key component is defined
in the schema as a date, then in the absence of a
data-type
attribute on the xsl:sort
element,
the sequence will be sorted in date order. With XSLT
1.0, the dates would be compared and sorted as
strings.
Certain operations that are permitted on untyped
data are not permitted on typed data, if the type of
the data is inappropriate for the operation.
For example, the
substring
FO
function expects its first argument to be a
string. It is acceptable to supply an untyped
value, which will be automatically converted to a
string, but it is not acceptable to supply a value
which has been annotated (as a result of schema
processing) as an integer or a date.
When an attribute value such as colors="red
green blue"
is processed without a schema, the
value is considered to be a single string. When
schema validation is applied, assuming the type is a
list type like xs:NMTOKENS
, the value
will be treated as a sequence of three strings. This
affects the results of many operations, for example
comparison of the value with another string.
With this attribute value, the expression
contains(@colors, "green")
returns true
in XPath 1.0 and also in XPath 2.0 if
input-type-annotations
is set to
strip
. In XPath 2.0, with a schema-aware
processor and with
input-type-annotations
set to
preserve
, the same expression returns
false with backwards-compatibility enabled, and
raises an error with backwards compatibility
disabled.
Information about incompatibilities between XPath 2.0 and XPath 1.0 is included in [XPath 2.0]
Incompatibilities in the specification of individual functions in the core function library are listed in [Functions and Operators]
This section summarizes the new functionality offered in XSLT 2.0, compared with XSLT 1.0. These are arranged in three groups. Firstly, the changes that pervade the entire text. Secondly, the major new features introduced. And thirdly, a catalog of minor technical changes.
Changes since the November 2006 Proposed Recommendation are listed separately: see J.2.4 Changes since Proposed Recommendation.
In addition to these changes, reported errors in XSLT 1.0 have been fixed.
There has been significant re-arrangement of the text. More terminology definitions have been hyperlinked, and a glossary (see C Glossary) has been added. Additional appendices summarize the error conditions and implementation-defined features of the specification.
The specifications of many features (for example
keys, xsl:number
, the
format-number
function, the xsl:import
mechanism, and the description of attribute sets)
have been rewritten to make them clearer and more
precise.
Many changes have been made to support the
XDM data model, notably the support for
sequences as a replacement for the node-sets of XPath
1.0. This has affected the specification of elements
such as xsl:for-each
,
xsl:value-of
,
and xsl:sort
, and has
led to the introduction of new instructions such as
xsl:sequence
.
The processing model is described differently: instead of instructions "writing to the result tree", they now return sequences of values. This change is largely one of terminology, but it also means that it is now possible for XSLT stylesheets to manipulate arbitrary sequences, including sequences containing parentless element or attribute nodes.
The description of the evaluation context has been changed. The concepts of current node and current node list have been replaced by the XPath concepts of context item, context position, and context size.
With the introduction of support for XML Schema within XPath 2.0, XSLT now supports stronger data typing, while retaining backwards compatibility. In particular, the types of variables and parameters can now be specified explicitly, and schema validation can be invoked for result trees and for elements and attributes in temporary trees.
The description of error handling has been improved (see 2.9 Error Handling). This formalizes the difference between static and dynamic errors, and tightens the rules that define which errors must be signaled under which conditions.
The terms implementation-defined and implementation-dependent are now defined and used consistently, and a checklist of implementation-defined features is provided (see F Checklist of Implementation-Defined Features).
XSLT 2.0 is designed to work with XPath 2.0 rather than XPath 1.0. This brings an enhanced data model with a type system based on sequences of nodes or atomic values, support for all the built-in types defined in XML Schema, and a wide range of new functions and operators.
The result tree fragment data-type is eliminated.
A variable-binding
element with content (and no as
attribute) now constructs a temporary tree, and the
value of the variable is the root node of this tree
(see 9.3 Values of
Variables and Parameters). With an
as
attribute, a variable-binding element
may be used to construct an arbitrary sequence. These
features eliminate the need for the
xx:node-set
extension function provided
by many XSLT 1.0 implementations.
Facilities are introduced for grouping of nodes
(the xsl:for-each-group
instruction, and the current-group()
and
current-grouping-key()
functions). See
14 Grouping
It is now possible to create user-defined functions within the stylesheet, that can be called from XPath expressions. See 10.3 Stylesheet Functions.
A transformation is allowed to produce multiple result trees. See 19.1 Creating Final Result Trees.
A new instruction xsl:analyze-string
is provided to process text by matching it against a
regular expression.
It is possible to declare the types of variables
and parameters, and the result types of templates and
functions. The types may either be built-in types, or
user-defined types imported from a schema using a new
xsl:import-schema
declaration.
A stylesheet is able to attach type annotations to elements and attributes in a result tree, and also in temporary trees, and to make use of any type annotations that exist in a source tree. Result trees and temporary trees can be validated against a schema.
A transformation may now be invoked by calling a
named template. This creates the potential for a
transformation to process large collections of input
documents. The input to such a transformation
may be obtained using the
collection
FO
function defined in [Functions and Operators], or
it may be supplied as a stylesheet
parameter.
Comparisons between values used for grouping, for sorting, and for keys can be performed using the rules for any supported data type, including the ability to select named collations for performing string comparison. These complement the new facilities in XPath 2.0, which are also invoked automatically when matching template rules.
The xsl:for-each
instruction is able to process any sequence, not only
a sequence of nodes.
An XHTML output method has been added. The details are described in [XSLT and XQuery Serialization].
A collation
attribute has been added
to the xsl:sort
element to
allow sorting using a user-defined collation.
A new xsl:next-match
is provided to allow multiple template rules to be
applied to the same source node.
A new xsl:character-map
declaration is available to control the serialization
of individual characters. This is intended as a
replacement for some use-cases where
disable-output-escaping
was previously
necessary.
Functions have been added for formatting dates and times. See 16.5 Formatting Dates and Times
The new facility of tunnel parameters allows parameters to be set that affect an entire phase of the transformation, without requiring them to be passed explicitly in every template call.
Many instructions that previously constructed a
value using child instructions can now alternatively
construct the value using a select
attribute; and conversely, instructions that
previously required a select
attribute
can now use child instructions.
The xsl:template
declaration can now declare a template rule that
applies to several different modes; and the xsl:apply-templates
instruction can cause processing to continue in the
current mode.
Instead of allowing the output method complete freedom to add namespace nodes, a process of namespace fixup is applied to the result tree before it is output; this same namespace fixup process is also applied to documents constructed using variable-binding elements with content (see 5.7.3 Namespace Fixup).
Support for XML Base has been added.
An xsl:apply-imports
element is allowed to have parameters (see 6.7 Overriding Template
Rules and 10.1.1
Passing Parameters to Templates).
Extension functions are allowed to return external objects, which do not have any of the builtin XPath types.
The specification for patterns (5.5 Patterns) has been revised to align it with the new XPath grammar. The formal semantics of patterns has been simplified: this became possible because of the extra compositionality now available in the expression grammar. The syntax and semantics of patterns remains essentially unchanged, except that XPath 2.0 expressions can be used within predicates.
A backwards-compatible processing mode is introduced. See 3.8 Backwards-Compatible Processing
The system-property
function now always returns a string. Several new
system properties have been defined. See 16.6.5
system-property.
With <xsl:message
terminate="yes">
, the processor now
must terminate
processing. Previously the word should was used. See 17 Messages.
A number of new serialization parameters have been introduced.
A new instruction xsl:namespace
is available, for creating namespace nodes: see
11.7 Creating
Namespace Nodes.
A new instruction xsl:perform-sort
is available, for returning a sorted sequence.
A new [xsl:]xpath-default-namespace
attribute is available to define the default
namespace for unqualified names in an XPath
expression or XSLT pattern.
The attributes [xsl:]version
,
[xsl:]exclude-result-prefixes
, and
[xsl:]extension-element-prefixes
, as
well as the new
[xsl:]xpath-default-namespace
and
[xsl:]default-collation
, can be used on
any XSLT element, not only on
xsl:stylesheet
and on literal result elements as before. In
particular, they can now be used on the xsl:template
element.
A new unparsed-text
function is introduced. It allows the contents of an
external text file to be read as a string.
Restrictions on the use of variables within
patterns and key definitions have been removed; in
their place a more general statement of the
restrictions preventing circularity has been
formulated. The current
function
may also now be used within patterns.
The built-in templates for element and document nodes now pass any supplied parameter values on to the templates that they call.
A detailed specification of the format-number
function is now provided, removing the reliance on
specifications in Java JDK 1.1.
The following changes have been made since publication of the Proposed Recommendation. Each change contains a reference to its discussion and rationale, for example the relevant issue number in the W3C public Bugzilla database.
In 15.1 The xsl:analyze-string instruction, the paragraph describing the permitted contents of the instruction has been clarified. (The sentence "Both elements are optional, and neither may appear more than once." was considered awkward). This editorial change was made in response to a public comment made during the Candidate Recommendation phase.
In 19 Final Result Trees it was stated that the result of a transformation consisted of zero or more result trees; while 2.4 Executing a Transformation stated (correctly) that it consisted of one or more. The former statement has been revised. A cross-reference between the two sections has been added for clarification. (Bugzilla 4031)
Some trivial syntax errors in examples have been fixed. (Bugzilla 4149)
The Proposed Recommendation contains a complete list of published working drafts prepared during the development of this specification, and a detailed history of changes may be assembled by viewing the change log present in each draft. For most of the drafts, a version is available in which changes are visually highlighted.


Inhibition of the Aspergillus brasiliensis ATCC 16404 growth by the thyme, clove, rosemary, and tea tree essential oils.
Figure 7


Call this when you want to make an angular component for use in your project.
yo scaffi:component
When a ui component is made, Scaffi creates it in the src/ui/app/components folder. This will give you an html and js controller. You can treat this as an app wide stub page.
Let's say we generated a component called 'code-example'. To use in a route's page or stub, we can do the following in the html template of that page/stub:


Introduction
Computers today have a variety of methods for information storage. Compact Disks, Digital Video Disks, Flash Drives, Secure Digital Cards, Hard Disk Drives, and Solid State Drives to name a few. This webpage will serve to inform about the last two items, Hard Disk Drives and Solid State Drives.
Installing a solid-state drive (SSD), also known as a solid-state disk, into your machine can radically ramp up its speed and reliability.*
* SSDs vs. HDDs: Why SSDs reign supreme.The two most common internal storage technologies are the Hard Disk Drive and the Solid State Drive. Hard Disk Drives are slower, bigger, cheaper devices that typically have a larger capacity than Solid State Drives. Solid State Drives are more expensive, but are smaller and very fast.
Why does speed matter? Almost every time you perform an action on your computer, files are retreived from the Hard Drive. The faster the system can access and retreive those files, the faster the requested action is performed.
Many factors come into play that affect the speed of a Hard Disk Drive. One of the reasons that SSDs are so much faster than HDDs is that they have no moving parts. Performance in Hard Disk Drives is based on but not limited to:
- Access Time
- Seek Time
- Rotational Latency
- Command Processing Time
- Settle Time Time
- Data Transfer Rate
- Interleave
Hard Disk Drives
Hard disk drives store digital information in a relatively permanent form.
from howstuffworks.comHard Disk Drives are made up of a spinning disk which is coated in magnetic material as well as a magnetic head on an actuator arm that is used for reading and writing.
History
Hard Disk Drives were introduced in late 1950's and were developed by IBM in order to calculate sports results for the Olympics.
Form Factor
The first standardized size of HDDs were 14" platters. Eventually HDD form factors follow the progression of floppy disk drives and included sizes such as 8", 5.25" 3.5", 2.5", 1.8", 1", and 0.85". Currently, 3.5" and 2.5" inch are the most common sizes for desktops and laptops respectively.
The main benefit to disk drives over solid state drives is that they are much cheaper and higher capacity. Today a 3TB hard drive will cost only about $150.00 Canadian, while the capacity of a $150.00 SSD would be around 60-120GB.
Solid State Drives
Solid state drives utilize flash memory rather than spinning magnetic disks in order to store data. Flash memory is much faster than traditional storage methods and upgrading your personal computer from a HDD to an SSD will be the most noticeable difference in responsiveness out of any possible upgrade.
The PCIe-based VeloDrive has the ability to deliver transfer speeds of up to 1GB/s.
from pclaunches.comHistory
Flash memory has been around since the 1970's but it hasn't existed in the personal computer market for very long. Trends show that the prices on SSDs are decreasing while the capacity continues to grow.
Form Factor
SSDs can come in multiple forms. Some forms are like traditional hard disk drives in 2.5" and 3.5" inch form factors, but others come on PCI and PCI express cards and interface directly with the computer's motherboard, rather than through a SATA connector.
Pictured on the left is a comparison of 2.5" and 3.5" inch form factors. Typically, SSD's come in the smaller form, and an adapter bracket is used in order to place the drive into a standard desktop computer case.
Although similar to 2.5" HDDs in size, solid state drives are significantly lighter than their disk spinning counterparts. While weight may not make a big difference in a desktop computer, it is an important factor in the mobility of notebook computers.


LAPTOP-UE-0_2_LAPTOP-UE-8 [TCP, 1 st.]
LAPTOP-UE-0 → LAPTOP-UE-8 Results
By Buffer Size
By Time
LAPTOP-UE-8 → LAPTOP-UE-0 Results
By Buffer Size
By Time


Former violinist turned whatever this is I am these days
This will introduce you to several of my skills.
Feel free to contact me on Twitter at: @JeffRush


Reset
Player X wins!!
Play again?
Player O wins!!
Cat's game!Nobody wins!
Player X, it's your move!
Player O, it's your move!


In this post I'm just going to demonstrate some simple html and css for a button with a rollover effect and rounded corners. You can find samples like this all over the internet, but this is the standard way I like to do it, and I know it works nicely with all the browsers.
Start with some simple HTML. Your anchor tag around the outside to cover the whole button, and you're going to need three spans inside it to style the three separate parts of the button (the left end, the middle bit and the right end).
  Button Text
You'll notice I've used two classes, one to define that this is a hover button, and the second to define the specific type of logo we are going to use on the button.
Next you need some CSS. First we need define the button size. We need a fixed height, but we leave the width variable. We use a line-height on the span to keep the text vertically centred. You can specify margins that suit you.
.rolloverButton { margin: 5px; height: 23px; display: block; } .rolloverButton span { float: left; height: 23px; line-height: 23px; }
Next we can use the second CSS class to provide the background image.
.arrowButton span { background: transparent url('linkbutton-combined.png') no-repeat scroll; color: white; }
Your image should be composed of your two button states stacked horizontally like this. The image must be exactly twice the height of your button and long enough to cope with the longest possible content you are going to want to use. If you want to take advantage of the transparency on the corners it will need to be a png file.
Now we just need to position the image on each of the spans so the correct part is shown. The padding sizes specified here should match the width of the corner part of your button image. The padding ensures that the three spans are spaced correctly and do no overlap.
.rolloverButton .left { padding-left: 21px; background-position: left top; } .rolloverButton .mid { background-position: -21px 0px; } .rolloverButton .right { padding-left: 21px; background-position: right top; }
Finally we need to adjust the image location when the user hovers over the button.
.rolloverButton:hover .left { background-position: left bottom; } .rolloverButton:hover .mid { background-position: -21px bottom; } .rolloverButton:hover .right { background-position: right bottom; }
And there you have it, a flexible width rollover button that works in IE, Chrome and Firefox. (Remember if your targeting IE6, it doesn't support transparent PNGs, so you'll need to make sure your image background matches the background you place the button on.)
Button Text


Headquartered in Asia, we have local intel and in-house expertise in the region’s fastest growing markets. Our listed subsidiaries include Shangri-La Hotels Berhad (Malaysia) and Shangri-La Hotel Public Company Limited (Thailand).
Our subsidiary Shangri-La Hotels (Malaysia) Berhad owns and operates hotels and beach resorts, a golf course, investment properties and commercial laundry. Shangri-La Hotels (Malaysia) Berhad is incorporated with limited liability in Malaysia and traded on the Bursa Malaysia Securities Berhad (stock code 5517)
Our subsidiary Shangri-La Hotel Public Company Limited (Thailand) is an investment holding company whose principal activities are investment properties and operation of hotels and resorts. Shangri-La Hotel Public Company Limited is incorporated with limited liability in Thailand and traded on the Stock Exchange of Thailand (stock code SHANG).


--- title: Tutorial type: doc ---
From wikipedia:
The primary purpose of the dependency injection pattern is to allow selection among multiple implementations of a given dependency interface at runtime, or via configuration files, instead of at compile time. The pattern is particularly useful for providing "mock" test implementations of complex components when testing but is often used for locating plugin components, or locating and initializing software services.
Let's say you're coding a beautiful application that controls a sump pump:
After a careful design phase (see this blog post to have an accurate description of this phase), you come up with a SumpPump class:
class SumpPump
{
public:
...
void Drain()
{
if ( probe -> MustDrain() )
engine -> On();
else
engine -> Off();
}
private:
PumpEngine* engine;
SumpProbe* probe;
};
Let's say you now have a new requirement:
to prevent explosions, the pump must not be operated when methane is above a certain level.
No problem: you're using OO. You can subclass PumpEngine and change the code this way:
class SafeEngine : public PumpEngine
{
public:
virtual void On()
{
if ( ! sensor -> IsCritical() )
PumpEngine::On();
}
private:
GasSensor* sensor;
};
class SumpPump
{
public:
void Drain()
{
if ( probe -> MustDrain() )
engine -> On();
else
engine -> Off();
}
private:
PumpEngine* engine;
SumpProbe* probe;
};
However, somewhere in the code, you must tell the class SumpPump to create an instance of SafeEngine instead of PumpEngine. There are two solutions:
class SumpPump
{
public:
SumpPump( GasSensor* sensor )
{
// engine = new PumpEngine();
engine = new SafeEngine( sensor );
probe = new SumpProbe();
}
...
};
class SumpPump
{
public:
SumpPump( PumpEngine* pe, SumpProbe* sp ) :
engine( pe ),
probe( sp )
{
}
...
};
Both the solutions have problems.
In the first, you have to modify the code of SumpPump if you want to use a different engine. Besides, you need to provide the SafeEngine constructor parameters to the SumpPump constructor (and so, you have to modify also the code that creates SumpPump instances).
The second solution is better: you don't change SumpPump code, yet you can't swap the behavior without recompiling your application.
Instead, I really would like to be able to change the type of the classes without modifying them and without propagating dependencies in the whole class tree.
Let's say I want the freedom to choose late the concrete classes of probe and engine dependencies in SumpPump.
Using Wallaroo we can write the classes this way:
// sumppump.h
class SumpPump : public Part
{
public:
SumpPump();
virtual void Drain();
private:
Collaborator< SumpProbe > probe;
Collaborator< PumpEngine > engine;
};
and
// sumppump.cpp
WALLAROO_REGISTER( SumpPump )
SumpPump::SumpPump() :
probe( "probe", RegistrationToken() ),
engine( "engine", RegistrationToken() )
{
}
void SumpPump::Drain()
{
if ( probe -> MustDrain() ) engine -> On();
else engine -> Off();
}
Then, let's say I want to use TwoLevelSumpProbe and SafeEngine as concrete classes of probe and engine, respectively.

Catalog catalog;
XmlConfiguration file( "wiring.xml" );
file.Fill( catalog );
catalog.CheckWiring(); // throws a WiringError exception if any collaborator is missed
the xml file should have this syntax (see here for a detailed description):
<wallaroo>
<parts>
<part>
<name>twoLevelsProbe</name>
<class>TwoLevelSumpProbe</class>
</part>
<part>
<name>safeEngine</name>
<class>SafeEngine</class>
</part>
<part>
<name>pump</name>
<class>SumpPump</class>
</part>
</parts>
<wiring>
<wire>
<source>pump</source>
<dest>twoLevelsProbe</dest>
<collaborator>probe</collaborator>
</wire>
<wire>
<source>pump</source>
<dest>safeEngine</dest>
<collaborator>engine</collaborator>
</wire>
</wiring>
</wallaroo>
(If you think the xml file is a bit too verbose you should use wal format instead)
You can also decide to put your classes in shared libraries. Let's say you wanna put SafeEngine class in a .dll or .so. You just substitute the macro WALLAROO_REGISTER with WALLAROO_DYNLIB_REGISTER in this way:
// safeengine.cpp
#include "pumpengine.h"
#include "wallaroo/dynamic_lib.h" // once per library
#include "wallaroo/dyn_registered.h" // once per translation unit
class SafeEngine : public PumpEngine
{
public:
virtual void On()
{
if ( ! sensor -> IsCritical() )
PumpEngine::On();
}
private:
Collaborator< GasSensor > sensor;
};
WALLAROO_DYNLIB_REGISTER( SafeEngine )
Then, you should load the shared library before create your objects:
Plugin::Load( "safeengine" + Plugin::Suffix() ); // load classes in shared libraries.
// Plugin::Suffix() expands to .dll or .so according to the OS
Catalog catalog;
XmlConfiguration file( "wiring.xml" );
file.Fill( catalog );
catalog.CheckWiring(); // throws a WiringError exception if any collaborator is missing
The shared library can also be specified in the xml configuration file:
<wallaroo>
<plugins>
<shared>safeengine</shared>
</plugins>
<parts>
<part>
<name>twoLevelsProbe</name>
<class>TwoLevelSumpProbe</class>
</part>
<part>
<name>safeEngine</name>
<class>SafeEngine</class>
</part>
<part>
<name>pump</name>
<class>SumpPump</class>
</part>
</parts>
<wiring>
<wire>
<source>pump</source>
<dest>twoLevelsProbe</dest>
<collaborator>probe</collaborator>
</wire>
<wire>
<source>pump</source>
<dest>safeEngine</dest>
<collaborator>engine</collaborator>
</wire>
</wiring>
</wallaroo>
In this case, you should load the shared libraries in this way:
Catalog catalog;
XmlConfiguration file( "wiring.xml" );
file.LoadPlugins(); // load the shared libraries specified in the configuration file
file.Fill( catalog );
catalog.CheckWiring(); // throws a WiringError exception if any collaborator is missing
Finally, you can get the entry point and start the main loop:
shared_ptr< SumpPump > pump = catalog[ "pump" ];
while ( true )
pump -> Drain();
That's all. If you want, you can have a look at the wallaroo mineplant sample to see all the details about this example.


This module was contributed by Chris Moyer. It provides a subclass of the SQS Message class that supports YAML as the body of the message.
This module requires the yaml module.
The YAMLMessage class provides a YAML compatible message. Encoding and decoding are handled automaticaly.
Access this message data like such:
m.data = [ 1, 2, 3] m.data[0] # Returns 1
This depends on the PyYAML package


☰
Profile
Stats
Graph
About
Log Out
Log In
Sign Up
Offline Mode
Username:
Password:
Log in
Close
Username:
Password:
Email:
Sign Up
Close
Edit
Save
Update Profile Picture
Upload from Camera:
Upload from Files:
Option1
View Graph
Stats
Games:
Goals:
Assists:
Minutes:
Passes:
Submit
Graph Options
Line
Bar
Scatter
Pie
Points:
1
2
3
4
5
6
Submit
Create a Line Graph
Graph Name:
X Axis Title:
Create Graph
Save Graph
View an example
Create a PieChart
Graph Name:
Create Chart
Save Chart
Create a BarChart
Graph Name:
Create Chart
Save Chart
Create a ScatterChart
Random Chart
Update
Close
Back


SCSI_ID
Section: Linux Administrator's Manual (8)Updated: December 2003
Index Return to Main Contents
NAME
scsi_id - retrieve and generate a unique SCSI identifierSYNOPSIS
scsi_id [options]DESCRIPTION
scsi_id queries a SCSI device via the SCSI INQUIRY vital product data (VPD) page 0x80 or 0x83 and uses the resulting data to generate a value that is unique across all SCSI devices that properly support page 0x80 or page 0x83.If a result is generated it is sent to standard output, and the program exits with a zero value. If no identifier is output, the program exits with a non-zero value.
scsi_id is primarily for use by other utilities such as udev that require a unique SCSI identifier.
By default all devices are assumed black listed, the --whitelisted option must be specified on the command line or in the config file for any useful behaviour.
SCSI commands are sent directly to the device via the SG_IO ioctl interface.
In order to generate unique values for either page 0x80 or page 0x83, the serial numbers or world wide names are prefixed as follows.
Identifiers based on page 0x80 are prefixed by the character 'S', the SCSI vendor, the SCSI product (model) and then the the serial number returned by page 0x80. For example:
# /lib/udev/scsi_id --page=0x80 --whitelisted --device=/dev/sda SIBM 3542 1T05078453
Identifiers based on page 0x83 are prefixed by the identifier type followed by the page 0x83 identifier. For example, a device with a NAA (Name Address Authority) type of 3 (also in this case the page 0x83 identifier starts with the NAA value of 6):
# /lib/udev/scsi_id --page=0x83 --whitelisted --device=/dev/sda 3600a0b80000b174b000000d63efc5c8c
OPTIONS
- --blacklisted
- The default behaviour - treat the device as black listed, and do nothing unless a white listed device is found in the scsi_id config-file.
- --device=device
- Send SG_IO commands to device, such as /dev/sdc.
- --config=config-file
- Read configuration and black/white list entries from config-file rather than the default /etc/scsi_id.config file.
- --whitelisted
- Treat the device as white listed. The --whitelisted option must be specified on the command line or in the scsi_id configuration file for scsi_id to generate any output.
- --page=0x80|0x83|pre-spc3-83|0x80-0x83|0x83-0x80
-
Use SCSI INQUIRY VPD page code 0x80, 0x83, or pre-spc3-83.
The default behaviour is to query the available VPD pages, and use page 0x83 if found, else page 0x80 if found, else nothing.
Page pre-spc3-83 should only be utilized for those scsi devices which are not compliant with the SPC-2 or SPC-3 format for page 83. While this option is used for older model 4, 5, and 6 EMC Symmetrix devices, its use with SPC-2 or SPC-3 compliant devices will fallback to the page 83 format supported by these devices.
0x80-0x83 is like 0x80, and exports ID_SERIAL and ID_SERIAL_80, but also exports 0x83 in ID_SERIAL_83.
0x83-0x80 is like 0x83, and exports ID_SERIAL and ID_SERIAL_83, but also exports 0x80 in ID_SERIAL_80.
- --replace-whitespace
- Reformat the output : replace all whitespaces by underscores.
- --export
- Export all data in KEY=<value> format used to import in other programs.
- --verbose
- Generate verbose debugging output.
- --version
-
Display version number and exit.
FILES
- /etc/scsi_id.config
- Configuration of black/white list entries and per device options: # one config per line, short match strings match longer strings # vendor=string[,model=string],options=<per-device scsi_id command line options> vendor="ATA",options=-p 0x80
SEE ALSO
udev(7)AUTHORS
Developed by Patrick Mansfield<EMAIL_ADDRESS>based on SCSI ID source included in earlier linux 2.5 kernels, sg_utils source, and SCSI specifications.
Index
This document was created by man2html, using the manual pages.
Time: 05:34:29 GMT, December 24, 2015


Mass shootings dominate America’s schedule
Days which a mass shooting occurred in the U.S.
Mass shooting occurred
2017
January
February
March
April
July
August
May
June
September
October
November
December
2018
January
February
Source: Gun Violence Archive
Mass shootings dominate America’s schedule
Days which a mass shooting occurred in the U.S.
Mass shooting occurred
2017
January
February
March
April
July
August
May
June
September
October
November
December
2018
January
February
Source: Gun Violence Archive
Mass shootings dominate America’s schedule
Days which a mass shooting occurred in the U.S.
Mass shooting occurred
2017
January
February
March
April
May
June
July
August
September
October
November
December
2018
January
February
Source: Gun Violence Archive


--- title: About navigation_match: /about/ description: "Read about styles and components used on sacha.me." ---
My name is Sacha Schmid. I'm a front-end developer from Switzerland, interested in both interface design and web development. I work at Die Medienmacher in Muttenz, Switzerland.
In 2017, I graduated from University of Applied Sciences and Arts Northwestern Switzerland in Brugg, Switzerland, majoring in Computer Science.
I have gathered experience in various aspects of front-end development and project management while working with companies and private clients alike, as well as a multitude of projects at university. You can see some of that work on my Projects page.
I keep up to date with the latest trends and the rapid evolution of languages and tools as much as possible, trying out new technologies on projects all the time. This interest in the industry allows me to create websites and applications that not only build on foundational principles of design, but also use cutting-edge technology.
I mainly work with HTML, CSS, and JavaScript. I like working with React, Redux, and similar technologies, but I am also familiar with frameworks like Angular. Apart from web languages, I have also worked with C#, Java, Haskell, and Swift.
Other than the web, I am very passionate about music, both listening to my favourite records and creating music with my guitars. Whenever I can, I like to go to concerts and festivals and just enjoy the music and the people around me.
This website was created using Jekyll. Also, Gulp was used to simplify some of the build processes, like compiling Sass files or combining and minifying assets. Entypo Icons are used throughout the site and icomoon was used to create the icon fonts.
The site is hosted on GitHub Pages. You can also view the site's source in order to find out more about involved technologies.
All content, unless otherwise noted, was created by me, Sacha Schmid. Copyright © 2013 – .


--- layout: post status: publish published: true title: New CDs author: display_name: Tomas Restrepo login: tomasr email<EMAIL_ADDRESS>url: http://winterdom.com/ author_login: tomasr author_email<EMAIL_ADDRESS>author_url: http://winterdom.com/ wordpress_id: 485 wordpress_url: http://winterdom.com/2002/04/newcds date: '2002-04-06 17:58:01 +0000' date_gmt: '2002-04-06 17:58:01 +0000' categories: - Personal tags: [] comments: [] ---
This afternoon I went looking around our local Tower Records store and came out with two new CDs for my music collection.
This time the turn was for Amorphis - Tuonela and for My Dying Bride - Like Gods of the Sun.