Class: Aws::LookoutEquipment::Types::SensorStatisticsSummary
| Relationships & Source Files | |
| Super Chains via Extension / Inclusion / Inheritance | |
|
Class Chain:
self,
Struct
|
|
|
Instance Chain:
self,
::Aws::Structure ,
Struct
|
|
| Inherits: |
Struct
|
| Defined in: | gems/aws-sdk-lookoutequipment/lib/aws-sdk-lookoutequipment/types.rb |
Overview
Summary of ingestion statistics like whether data exists, number of missing values, number of invalid values and so on related to the particular sensor.
Constant Summary
Instance Attribute Summary
-
#categorical_values ⇒ Types::CategoricalValues
rw
Parameter that describes potential risk about whether data associated with the sensor is categorical.
-
#component_name ⇒ String
rw
Name of the component to which the particular sensor belongs for which the statistics belong to.
-
#data_end_time ⇒ Time
rw
Indicates the time reference to indicate the end of valid data associated with the sensor that the statistics belong to.
-
#data_exists ⇒ Boolean
rw
Parameter that indicates whether data exists for the sensor that the statistics belong to.
-
#data_start_time ⇒ Time
rw
Indicates the time reference to indicate the beginning of valid data associated with the sensor that the statistics belong to.
-
#duplicate_timestamps ⇒ Types::CountPercent
rw
Parameter that describes the total number of duplicate timestamp records associated with the sensor that the statistics belong to.
-
#invalid_date_entries ⇒ Types::CountPercent
rw
Parameter that describes the total number of invalid date entries associated with the sensor that the statistics belong to.
-
#invalid_values ⇒ Types::CountPercent
rw
Parameter that describes the total number of, and percentage of, values that are invalid for the sensor that the statistics belong to.
-
#large_timestamp_gaps ⇒ Types::LargeTimestampGaps
rw
Parameter that describes potential risk about whether data associated with the sensor contains one or more large gaps between consecutive timestamps.
-
#missing_values ⇒ Types::CountPercent
rw
Parameter that describes the total number of, and percentage of, values that are missing for the sensor that the statistics belong to.
-
#monotonic_values ⇒ Types::MonotonicValues
rw
Parameter that describes potential risk about whether data associated with the sensor is mostly monotonic.
-
#multiple_operating_modes ⇒ Types::MultipleOperatingModes
rw
Parameter that describes potential risk about whether data associated with the sensor has more than one operating mode.
-
#sensor_name ⇒ String
rw
Name of the sensor that the statistics belong to.
Instance Method Summary
::Aws::Structure
- Included
| #to_hash | Alias for Structure#to_h. |
Instance Attribute Details
#categorical_values ⇒ Types::CategoricalValues (rw)
Parameter that describes potential risk about whether data associated with the sensor is categorical.
# File 'gems/aws-sdk-lookoutequipment/lib/aws-sdk-lookoutequipment/types.rb', line 3307
class SensorStatisticsSummary < Struct.new( :component_name, :sensor_name, :data_exists, :missing_values, :invalid_values, :invalid_date_entries, :, :categorical_values, :, :, :monotonic_values, :data_start_time, :data_end_time) SENSITIVE = [] include Aws::Structure end
#component_name ⇒ String
(rw)
Name of the component to which the particular sensor belongs for which the statistics belong to.
# File 'gems/aws-sdk-lookoutequipment/lib/aws-sdk-lookoutequipment/types.rb', line 3307
class SensorStatisticsSummary < Struct.new( :component_name, :sensor_name, :data_exists, :missing_values, :invalid_values, :invalid_date_entries, :, :categorical_values, :, :, :monotonic_values, :data_start_time, :data_end_time) SENSITIVE = [] include Aws::Structure end
#data_end_time ⇒ Time
(rw)
Indicates the time reference to indicate the end of valid data associated with the sensor that the statistics belong to.
# File 'gems/aws-sdk-lookoutequipment/lib/aws-sdk-lookoutequipment/types.rb', line 3307
class SensorStatisticsSummary < Struct.new( :component_name, :sensor_name, :data_exists, :missing_values, :invalid_values, :invalid_date_entries, :, :categorical_values, :, :, :monotonic_values, :data_start_time, :data_end_time) SENSITIVE = [] include Aws::Structure end
#data_exists ⇒ Boolean
(rw)
Parameter that indicates whether data exists for the sensor that the statistics belong to.
# File 'gems/aws-sdk-lookoutequipment/lib/aws-sdk-lookoutequipment/types.rb', line 3307
class SensorStatisticsSummary < Struct.new( :component_name, :sensor_name, :data_exists, :missing_values, :invalid_values, :invalid_date_entries, :, :categorical_values, :, :, :monotonic_values, :data_start_time, :data_end_time) SENSITIVE = [] include Aws::Structure end
#data_start_time ⇒ Time
(rw)
Indicates the time reference to indicate the beginning of valid data associated with the sensor that the statistics belong to.
# File 'gems/aws-sdk-lookoutequipment/lib/aws-sdk-lookoutequipment/types.rb', line 3307
class SensorStatisticsSummary < Struct.new( :component_name, :sensor_name, :data_exists, :missing_values, :invalid_values, :invalid_date_entries, :, :categorical_values, :, :, :monotonic_values, :data_start_time, :data_end_time) SENSITIVE = [] include Aws::Structure end
#duplicate_timestamps ⇒ Types::CountPercent (rw)
Parameter that describes the total number of duplicate timestamp records associated with the sensor that the statistics belong to.
# File 'gems/aws-sdk-lookoutequipment/lib/aws-sdk-lookoutequipment/types.rb', line 3307
class SensorStatisticsSummary < Struct.new( :component_name, :sensor_name, :data_exists, :missing_values, :invalid_values, :invalid_date_entries, :, :categorical_values, :, :, :monotonic_values, :data_start_time, :data_end_time) SENSITIVE = [] include Aws::Structure end
#invalid_date_entries ⇒ Types::CountPercent (rw)
Parameter that describes the total number of invalid date entries associated with the sensor that the statistics belong to.
# File 'gems/aws-sdk-lookoutequipment/lib/aws-sdk-lookoutequipment/types.rb', line 3307
class SensorStatisticsSummary < Struct.new( :component_name, :sensor_name, :data_exists, :missing_values, :invalid_values, :invalid_date_entries, :, :categorical_values, :, :, :monotonic_values, :data_start_time, :data_end_time) SENSITIVE = [] include Aws::Structure end
#invalid_values ⇒ Types::CountPercent (rw)
Parameter that describes the total number of, and percentage of, values that are invalid for the sensor that the statistics belong to.
# File 'gems/aws-sdk-lookoutequipment/lib/aws-sdk-lookoutequipment/types.rb', line 3307
class SensorStatisticsSummary < Struct.new( :component_name, :sensor_name, :data_exists, :missing_values, :invalid_values, :invalid_date_entries, :, :categorical_values, :, :, :monotonic_values, :data_start_time, :data_end_time) SENSITIVE = [] include Aws::Structure end
#large_timestamp_gaps ⇒ Types::LargeTimestampGaps (rw)
Parameter that describes potential risk about whether data associated with the sensor contains one or more large gaps between consecutive timestamps.
# File 'gems/aws-sdk-lookoutequipment/lib/aws-sdk-lookoutequipment/types.rb', line 3307
class SensorStatisticsSummary < Struct.new( :component_name, :sensor_name, :data_exists, :missing_values, :invalid_values, :invalid_date_entries, :, :categorical_values, :, :, :monotonic_values, :data_start_time, :data_end_time) SENSITIVE = [] include Aws::Structure end
#missing_values ⇒ Types::CountPercent (rw)
Parameter that describes the total number of, and percentage of, values that are missing for the sensor that the statistics belong to.
# File 'gems/aws-sdk-lookoutequipment/lib/aws-sdk-lookoutequipment/types.rb', line 3307
class SensorStatisticsSummary < Struct.new( :component_name, :sensor_name, :data_exists, :missing_values, :invalid_values, :invalid_date_entries, :, :categorical_values, :, :, :monotonic_values, :data_start_time, :data_end_time) SENSITIVE = [] include Aws::Structure end
#monotonic_values ⇒ Types::MonotonicValues (rw)
Parameter that describes potential risk about whether data associated with the sensor is mostly monotonic.
# File 'gems/aws-sdk-lookoutequipment/lib/aws-sdk-lookoutequipment/types.rb', line 3307
class SensorStatisticsSummary < Struct.new( :component_name, :sensor_name, :data_exists, :missing_values, :invalid_values, :invalid_date_entries, :, :categorical_values, :, :, :monotonic_values, :data_start_time, :data_end_time) SENSITIVE = [] include Aws::Structure end
#multiple_operating_modes ⇒ Types::MultipleOperatingModes (rw)
Parameter that describes potential risk about whether data associated with the sensor has more than one operating mode.
# File 'gems/aws-sdk-lookoutequipment/lib/aws-sdk-lookoutequipment/types.rb', line 3307
class SensorStatisticsSummary < Struct.new( :component_name, :sensor_name, :data_exists, :missing_values, :invalid_values, :invalid_date_entries, :, :categorical_values, :, :, :monotonic_values, :data_start_time, :data_end_time) SENSITIVE = [] include Aws::Structure end
#sensor_name ⇒ String
(rw)
Name of the sensor that the statistics belong to.
# File 'gems/aws-sdk-lookoutequipment/lib/aws-sdk-lookoutequipment/types.rb', line 3307
class SensorStatisticsSummary < Struct.new( :component_name, :sensor_name, :data_exists, :missing_values, :invalid_values, :invalid_date_entries, :, :categorical_values, :, :, :monotonic_values, :data_start_time, :data_end_time) SENSITIVE = [] include Aws::Structure end


Accountability Made Easy
Organ Eyez provides an easy-to-use technology for activists and organizers to hold each other accountable.
Who is this app for?
Community organizations and social justice groups, especially those with horizontal leadership structures
What does it do?
Why should I use it?


{% extends "myhome_base.html" %} {% load i18n %} {% block main_panel %}
{% trans "Tip: the latter way is more secure, but it is not supported well by all browsers. We advise you to use the latest version of Chrome or Firefox." %}


Mark Few is an American college basketball coach who has been the head coach at Gonzaga University since 1999. He has served on Gonzaga's coaching staff since 1989, and has been a constant on the sidelines throughout a period that has seen the Bulldogs rise from mid-major obscurity to regular participants in the NCAA Tournament. He has led the Bulldogs to the NCAA Tournament in every season during his tenure as head coach, a stretch that has garnered the Bulldogs recognition as one of the closest things to a major basketball power in a mid-major conference.


|
RFC 3470 |
| TOC |
|
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
Copyright © The Internet Society (2003). All Rights Reserved.
The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data.
There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols.
This document recommends, as policy, what specifications for Internet protocols -- and, in particular, IETF standards track protocol documents -- should include as normative language within them. The capitalized keywords "SHOULD", "MUST", "REQUIRED", etc. are used in the sense of how they would be used within other documents with the meanings as specified in BCP 14, RFC 2119 [1] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
|
RFC 3470 |
| TOC |
1.
Introduction and Overview
1.1.
Intended Audience
1.2.
Scope
1.3.
XML Evolution
1.4.
XML Users, Support Groups, and Additional Information
2.
XML Selection Considerations
3.
XML Alternatives
4.
XML Use Considerations and Recommendations
4.1.
XML Syntax and Well-Formedness
4.2.
XML Information Set
4.3.
Syntactic Restrictions
4.4.
XML Declarations
4.5.
XML Processing Instructions
4.6.
XML Comments
4.7.
Validity and Extensibility
4.8.
Semantics as Well as Syntax
4.9.
Namespaces
4.9.1.
Namespaces and Attributes
4.10.
Element and Attribute Design Considerations
4.11.
Binary Data and Text with Control Characters
4.12.
Incremental Processing
4.13.
Entity Declarations and Entity References
4.14.
External References
4.15.
URI Processing
4.16.
White Space
4.17.
Interaction with the IANA
5.
Internationalization Considerations
5.1.
Character Sets and Encodings
5.2.
Language Declaration
5.3.
Other Internationalization Considerations
6.
IANA Considerations
7.
Security Considerations
8.
Acknowledgements
9.
References
9.1.
Normative References
9.2.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
The Extensible Markup Language (XML, [8] (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” October 2000.)) is a framework for structuring data. While it evolved from the Standard Generalized Markup Language (SGML, [30] (International Organization for Standardization, “Information processing - Text and office systems - Standard Generalized Markup Language (SGML),” 1988.)) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data in protocol exchanges. See "XML in 10 points" [47] (W3C Communications Team, “XML in 10 points,” November 2001.) for an introduction to XML.
| TOC |
Many Internet protocol designers are considering using XML and XML fragments within the context of existing and new Internet protocols. This document is intended as a guide to XML usage and as IETF policy for standards track documents. Experienced XML practitioners will likely already be familiar with the background material here, but the guidelines are intended to be appropriate for those readers as well.
| TOC |
This document is intended to give guidelines for the use of XML content within a larger protocol. The goal is not to suggest that XML is the "best" or "preferred" way to represent data; rather, the goal is to lay out the context for the use of XML within a protocol once other factors point to XML as a possible data representation solution. The Common Name Resolution Protocol (CNRP, [24] (Popp, N., Mealling, M., and M. Moseley, “Common Name Resolution Protocol (CNRP),” August 2002.)) is an example of a protocol that would be addressed by these guidelines if it were being newly defined. This document does not address the use of protocols like SMTP or HTTP to send XML documents as ordinary email or web content.
There are a number of protocol frameworks already in use or under development which focus entirely on "XML protocol" -- the exclusive use of XML as the data representation in the protocol. For example, the World Wide Web Consortium (W3C) is developing an XML Protocol framework based on SOAP ([45] (Gudgin, M., Hadley, M., Moreau, JJ., and H. Nielsen, “SOAP Version 1.2 Part 1: Messaging Framework,” June 2002.) and [46] (Gudgin, M., Hadley, M., Moreau, JJ., and H. Nielsen, “SOAP Version 1.2 Part 2: Adjuncts,” June 2002.)). The applicability of such protocols is not part of the scope of this document.
In addition, there are higher-level representation frameworks, based on XML, that have been designed as carriers of certain classes of information; for example, the Resource Description Framework (RDF, [38] (Lassila, O. and R. Swick, “Resource Description Framework (RDF) Model and Syntax Specification,” February 1999.)) is an XML-based representation for logical assertions. This document does not provide guidelines for the use of such frameworks.
| TOC |
XML 1.0 was originally published as a W3C recommendation in February 1998 [35] (Bray, T., Paoli, J., and C. Sperberg-McQueen, “Extensible Markup Language (XML) 1.0,” February 1998.), and was revised in a 2nd edition [8] (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” October 2000.) in October 2000. Several additional facilities have also been defined that layer on the base specification. Although these additions are designed to be consistent with XML 1.0, they have varying levels of stability, consensus, and implementation. Accordingly, this document identifies the major evolutionary features of XML and makes suggestions as to the circumstances in which each feature should be used.
| TOC |
There are many XML support groups, with some devoted to the entire XML industry, some devoted to developers, some devoted to the business applications of XML, and many, many groups devoted to the use of XML in a particular context.
It is beyond the scope of this document to provide a comprehensive list of referrals. Interested readers are directed to the three references above as starting points, as well as their favorite Internet search engine.
| TOC |
XML is a tool that provides a means towards an end. Choosing the right tool for a given task is an essential part of ensuring that the task can be completed in a satisfactory manner. This section describes factors to be aware of when considering XML as a tool for use in IETF protocols:
| TOC |
This document focuses on guidelines for the use of XML. It is useful to consider why one might use XML as opposed to some other mechanism. This section considers some other commonly used representation mechanisms and compares XML to those alternatives.
For many fundamental protocols, the extensibility requirements are modest, and the performance requirements are high enough that fixed binary data blocks are the appropriate representation; mechanisms such as XML merely add bloat. RFC 3252 [23] (Kennedy, H., “Binary Lexical Octet Ad-hoc Transport,” April 2002.) describes a humorous example of XML as protocol bloat.
In addition, there are other representation and extensibility frameworks that have been used successfully within communication protocols. For example, Abstract Syntax Notation 1 (ASN.1) [28] (International Organization for Standardization, “Information Processing Systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1),” December 1990.) along with the corresponding Basic Encoding Rules (BER, [29] (International Organization for Standardization, “Information Processing Systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1),” December 1990.)) are part of the OSI communication protocol suite, and have been used in many subsequent communications standards (e.g., the ANSI Information Retrieval protocol [27] (American National Standards Institute, “Information Retrieval: Application Service Definition and Protocol Specification,” 1995.) and the Simple Network Management Protocol (SNMP, [13] (Case, J., Fedor, M., Schoffstall, M., and J. Davin, “Simple Network Management Protocol (SNMP),” May 1990.)). The External Data Representation (XDR, [14] (Srinivasan, R., “XDR: External Data Representation Standard,” August 1995.)) and variations of it have been used in many other distributed network applications (e.g., the Network File System (NFS) protocol [22] (Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, “NFS version 4 Protocol,” December 2000.)). With some ASN.1 encoding types, data types are explicit in the representation, while with XDR, the data types of components are described externally as part of an interface specification.
Many other protocols use data structures directly (without data encapsulation) by describing the data structure with Backus Normal Form (BNF, [25] (Backus, J., “The syntax and semantics of the proposed international algebraic language of the Zurich ACM-GAMM conference,” June 1959.)); many IETF protocols use an Augmented Backus-Naur Form (ABNF, [16] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.)). The Simple Mail Transfer Protocol (SMTP, [21] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.)) is an example of a protocol specified using ABNF.
ASN.1, XDR, and BNF are described here as examples of alternatives to XML for use in IETF protocols. There are other alternatives, but a complete enumeration of all possible alternatives is beyond the scope of this document.
Other representation methods may differ from XML in several important ways:
Text Encoding and character sets: the character encoding used to represent a formal specification. XML defines a consistent character model based on the Universal Character Set (UCS, [31] (International Organization for Standardization, “Information Technology - Universal Multiple-octet coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane,” May 1993.) and [33] (Unicode Consortium, “The Unicode Standard, as it may from time to time be revised or amended,” March 2002.)), and requires that XML parsers accept at least UTF-8 [4] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” January 1998.) and UTF-16 [20] (Hoffman, P. and F. Yergeau, “UTF-16, an encoding of ISO 10646,” February 2000.), and allows for other encodings. While ASN.1 and XDR may carry strings in any encoding, there is no common mechanism for defining character encodings within them. Typically, ABNF definitions tend to be defined in terms of octets or characters in ASCII.
Data Encoding: XML is defined as a sequence of characters, rather than a sequence of bytes. XML Schema [42] (Biron, P. and A. Malhotra, “XML Schema Part 2: Datatypes,” May 2001.) includes mechanisms for representing some data types (integer, date, array, etc.) but many binary data types are encoded in Base64 [15] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.) or hexadecimal. ASN.1 and XDR have rich mechanisms for encoding a wide variety of data types.
Extensibility: XML has a rich extensibility model such that XML specifications can frequently be versioned independently. Specifications can be extended by adding new element names and attributes (if done compatibly); other extensions can be added by defining new XML namespaces [9] (Bray, T., Hollander, D., and A. Layman, “Namespaces in XML,” January 1999.), though there is no standard mechanism in XML to indicating whether or not new extensions are mandatory to recognize. Similarly, there are several techniques available to extend ASN.1 specifications. XDR specifications tend to not be independently extensible by different parties because the framing and data types are implicit and not self-describing. The extensibility of BNF-based protocol elements needs to be explicitly planned.
Legibility of protocol elements: As noted above, XML is text-based, and thus carries the advantages (and disadvantages) of text-based protocol elements. Typically this is shared with (A)BNF-defined protocol elements. ASN.1 and XDR use binary encodings which are not easily human readable.
| TOC |
This section notes several aspects of XML and makes recommendations for use. Since the 1998 publication of XML version 1 [35] (Bray, T., Paoli, J., and C. Sperberg-McQueen, “Extensible Markup Language (XML) 1.0,” February 1998.), an editorial second edition [8] (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” October 2000.) was published in 2000; this section refers to the second edition.
| TOC |
XML [8] (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” October 2000.) is defined in terms of a concrete syntax: a sequence of characters, using the characters "<", "=", "&", etc. as delimiters. An instance is XML if and only if it is well-formed, i.e., all character and markup data conforms to the structural rules defined in section 2.1 of [8] (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” October 2000.).
Character and markup data that is not well-formed is not XML; well-formedness is the basis for syntactic compatibility with XML. Without well-formedness, all of the advantages of using XML disappear. For this reason, it is recommended that protocol specifications explicitly require XML well-formedness ("MUST be well-formed").
The IETF has a long-standing tradition of "be liberal in what you accept" that might seem to be at odds with this recommendation. Given that XML requires well-formedness, conformant XML parsers are intolerant of well-formedness errors. When specifying the handing of erroneous XML protocol elements, a protocol design must never recommend attempting to partially interpret non-well-formed instances of an element which is required to be XML. Reasonable behaviors in such a scenario could include attempting retransmission or aborting an in-progress session.
| TOC |
In addition to the concrete syntax of XML, there is an abstract model of XML content known as the "Information Set" (infoset) [37] (Cowan, J. and R. Tobin, “XML Information Set,” October 2001.). One might think of an XML parser as consuming the concrete syntax and producing an XML Information Set for further processing.
In typical use of XML, the definition of allowable XML documents is often defined in terms of the Information Set of the XML and not the concrete syntax. The notion is that any syntactic representation which yielded the same information set would be treated equivalently.
It some cases, protocols have been defined solely in terms of the XML Information Set, or by allowing other concrete syntax representations. However, since the context of XML embedded within other Internet protocols requires an unambiguous definition of the concrete syntax, defining an XML protocol element in terms of its XML Information Set alone and allowing other concrete syntax representations is out of scope for this document.
| TOC |
In some circumstances a protocol designer may be tempted to define an XML-based protocol element as "XML", but at the same time imposing additional restrictions beyond those imposed by the XML recommendation itself -- for example, restricting the document character encoding, or avoiding CDATA sections, character entity references, imposing additional restrictions on use of white space, etc. The general category of restrictions addressed by this section are ones that would allow some but not other of the set of syntactic representations which have the same canonical representation according to canonical XML described in RFC 3076 [6] (Boyer, J., “Canonical XML Version 1.0,” March 2001.).
Making these kinds of restrictions in a protocol definition may have the disadvantage that an implementer of the protocol may not be able to use an otherwise conforming XML processor to parse the XML-based protocol elements. In some cases, the motivation for subsetting XML is to allow implementers to build special-purpose processors that are lighter weight than a full-scale conforming XML processor. There are a number of good, conforming XML parsers that are small, fast, and free, while special-purpose processors have frequently been known to fail to handle some cases of legal XML syntax.
In general, such syntactic restrictions should be avoided. In circumstances where restrictions on the variability of the syntactic representation of XML is necessary for one reason or another, designers should consider using "Canonical XML" [6] (Boyer, J., “Canonical XML Version 1.0,” March 2001.) as the definition of the protocol element, since all such variability has been removed. Some specific issues are discussed in Section 4.4 (XML Declarations), Section 4.13 (Entity Declarations and Entity References), and Section 5.1 (Character Sets and Encodings) below.
| TOC |
An XML declaration (defined in section 2.8 of [8] (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” October 2000.)) is a small header at the beginning of an XML data stream that indicates the XML version and the character encoding used. For example,
<?xml version="1.0" encoding="UTF-8"?>
specifies the use of XML version 1 and UTF-8 character encoding.
In some uses of XML as an embedded protocol element, the XML used is a small fragment in a larger context, where the XML version is fixed at "1.0" and the character encoding is known to be "UTF-8". In those cases, an XML declaration might add extra overhead. In cases where the XML is a larger component which may find its way alone as an external entity body (transported as a MIME message, for example), the XML declaration is an important marker and is useful for reliability and extensibility. The XML declaration is also an important marker for character set/encoding (see Section 5.1 (Character Sets and Encodings)), if any encoding other than UTF-8 or UTF-16 is used. Note that in the case of UTF-16, XML requires that the entity starts with a Byte Order Mark (BOM), which is not part of the character data. Note that the XML Declaration itself is not part of the XML document's Information Set.
Protocol specifications must be clear about use of XML declarations. XML [8] (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” October 2000.) notes that "XML documents should begin with an XML declaration which specifies the version of XML being used." In general, an XML declaration should be encouraged ("SHOULD be present") and must always be allowed ("MAY be sent"). An XML declaration should be required in cases where, if allowed, the character encoding is anything other than UTF-8 or UTF-16.
| TOC |
An XML processing instruction (defined in section 2.6 of [8] (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” October 2000.)) is a component of an XML document that signals extra "out of band" information to the receiver; a common use of XML processing instructions are for document applications. For example, the XML2RFC application used to generate this document and described in RFC 2629 [19] (Rose, M., “Writing I-Ds and RFCs using XML,” June 1999.) supports a "table of contents" processing instruction:
<?rfc toc="yes"?>
As described in section 2.6 of [8] (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” October 2000.), processing instructions are not part of the document's character data, but must be passed through to the application. As a consequence, it is recommended that processing instructions be ignored when encountered in normal protocol processing. It is thus also recommended that processing instructions not be used to define normative protocol data structures or extensions for the following reasons:
| TOC |
An XML comment (defined in section 2.5 of [8] (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” October 2000.)) is a component of an XML document that provides descriptive information that is not part of the document's character data. XML comments, like comments used in programming languages, are often used to provide explanatory information in human-understandable terms. An example:
<!-- This is a example comment. -->
XML comments can be ignored by conformant processors. As a consequence, it is strongly recommended that comments not be used to define normative protocol data structures or extensions. It is thus also strongly recommended that comments be ignored if encountered in normal protocol processing.
| TOC |
One important value of XML is that there are formal mechanisms for defining structural and data content constraints; these constrain the identity of elements or attributes or the values contained within them. There is more than one such formalism:
There is ongoing discussion (and controversy) within the XML community on the use and applicability of various validity constraint mechanisms. The choice of tool depends on the needs for extensibility or for a formal language and mechanism for constraining permissible values and validating adherence to the constraints.
There are cases where protocols have defined validity using one or another validity mechanism, but the protocol definitions have not insisted that all corresponding protocol elements be "valid". The decision depends in part on the design for protocol extensibility. Each formalism has different ways of allowing for future extensions; in addition, a protocol design may have its own versioning mechanism, way of updating the schema, or pointing to a new one. For example, the use of XML namespaces (Section 4.9 (Namespaces)) with XML Schema allows other kinds of extensibility without compromising schema validity.
No matter what formalism is chosen, there are usually additional syntactic constraints, and inevitably additional semantic constraints, on the validity of XML elements that cannot be expressed in the formalism.
This document makes the following recommendations for the definition of protocols using XML:
An idealized model for XML processing might first check for well-formedness; if OK, apply the primary formalism and, if the instances "passes", apply the other constraints so that the entire set (or as much as is machine processable) can be checked at the same time.
However, it is reasonable to allow conforming implementations to avoid doing validation at run-time and rely instead on ad-hoc code to avoid the higher expense, for example, of schema validation, especially given that there will likely be additional hand-crafted semantic validation.
| TOC |
While the definition of an XML protocol element using a validity formalism is useful, it is not sufficient. XML by itself does not supply semantics. Any document defining a protocol element with XML MUST also have sufficient prose in the document describing the semantics of whatever XML the document has elected to define.
| TOC |
XML namespaces, defined in [9] (Bray, T., Hollander, D., and A. Layman, “Namespaces in XML,” January 1999.), provide a means of assigning markup to a specific vocabulary. If two elements or attributes from different vocabularies have the same name, they can be distinguished unambiguously if they belong to different namespaces. Additionally, namespaces provide significant support for protocol extensibility as they can be defined, reused, and processed dynamically.
Markup vocabulary collisions are very possible when namespaces are not used to separate and uniquely identify vocabularies. Protocol definitions should use existing XML namespaces where appropriate. When a new namespace is needed, the "namespace name" is a URI that is used to identify the namespace; it's also useful for that URI to point to a description of the namespace. Typically (and recommended practice in W3C) is to assign namespace names using persistent http URIs.
In the case of namespaces in IETF standards-track documents, it would be useful if there were some permanent part of the IETF's own web space that could be used for this purpose. In lieu of such, other permanent URIs can be used, e.g., URNs in the IETF URN namespace (see [11] (Mealling, M., Masinter, L., Hardie, T., and G. Klyne, “An IETF URN Sub-namespace for Registered Protocol Parameters,” March 2003.) and [12] (Mealling, M., “The IETF XML Registry,” June 2003.)). Although there are instances of IETF specifications creating new URI schemes to define XML namespaces, this practice is strongly discouraged.
| TOC |
There is a frequently misunderstood aspect of the relationship between unprefixed attributes and the default XML namespace - the natural assumption is that an unprefixed attribute is qualified by the default namespace, but this is not true. Rather, the unprefixed attribute belongs to no namespace at all. Thus, in the following example:
<ns1:fox a="xxx" ns1:b="qqq" xmlns="http://example.org"/> <fox a="xxx" ns1:b="qqq" xmlns="http://example.org" xmlns:ns1="http://example.org"/>
the attribute "a" is in no namespace, while "ns1:b" is the same namespace as the containing element. A specific description of the relationship between default namespaces and attributes can be found in section 5.2 of [9] (Bray, T., Hollander, D., and A. Layman, “Namespaces in XML,” January 1999.). The practical implication of the relationship between namespaces and attributes is that care must be taken to ensure that no element contains multiple attributes that have identical names or have qualified names with the same local part and with prefixes which have been bound to namespace names that are identical.
In XML applications, the choice between prefixed and non-prefixed attributes frequently is based on whether they always appear inside elements of the same namespace (in which case non-prefixed and thereby non-namespaced names are used) or whether it's required that they can be applied to elements in other arbitrary namespaces (in which case a prefixed name is used). Both situations occur in the XSLT [43] (Clark, J., “XSL Transformations (XSLT) Version 1.0,” November 1999.) language: while attributes are unprefixed when they occur inside elements in the XSLT namespace, such as:
<xsl:value-of select="."/>
they are prefixed when they appear in non-XSLT elements, such as the "xsl:version" attribute when using "literal result element stylesheets":
<html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/TR/xhtml1/strict"> <head> <title>Expense Report Summary</title> </head> <body> <p>Total: <xsl:value-of select="exp-rep/total"/></p> </body> </html>
| TOC |
XML provides much flexibility in allowing a designer to use either elements, attributes, or element content to carry data. This section gives a flavor of the design considerations; there is much written about this in the XML literature. Consistent use of elements, attributes, and values is an important characteristic of a sound design.
Attributes are generally intended to contain meta-data that describes the element, and as such they are subject to the following restrictions:
Consider the following example that describes an IP address using an attribute to describe the address value:
<address addrType="ipv4"><IP_ADDRESS></address>
One might encode the same information using an <addrType> element instead of an "addrType" attribute:
<address> <addrType>ipv4</addrType> <value><IP_ADDRESS></value> </address>
Another way of encoding the same information would be to use markup for the "addrType":
<address> <addrType><ipv4/></addrType> <value><IP_ADDRESS></value> </address>
Choosing between these designs involves tradeoffs concerning, among other considerations, the likely extensibility patterns and the ability of the formalism to constrain the values appropriately. In the first example, the attribute can be thought of as meta-data to the element which it modifies, and provides for a kind of "element extensibility". The third example allows for a different kind of extensibility: the "ipv4" space can be extended using other namespaces, and the <ipv4> element can include additional markup.
Many protocols include parameters that are selected from an enumerated set of values. Such enumerated values can be encoded as elements, attributes, or strings within element values. Any protocol design should consider how the set of enumerated values is to be extended: by revising the protocol, by including different values in different XML namespaces, or by establishing an IANA registry (as per RFC 2434 [18] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” October 1998.)). In addition, a common practice in XML is to use a URI as an XML attribute value or content.
Languages that describe syntactic validity (including XML Schema and DTDs) often provide a mechanism for specifying "default" values for an attribute. If an element does not specify a value for the attribute, then the "default" value is used. The use of default values for attributes is discouraged by this document. Although the use of this feature can reduce both the size and clutter of XML documents, it has a negative impact on software which doesn't know the document's validity constraints (e.g., for packet tracing or digital signature).
| TOC |
XML is defined as a character stream rather than a stream of octets. There is no way to embed raw binary data directly within an XML data stream; all binary data must be encoded as characters. There are a number of possible encodings; for example, XML Schema [42] (Biron, P. and A. Malhotra, “XML Schema Part 2: Datatypes,” May 2001.) defines encodings using decimal digits for integers, Base64 [15] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.), or hexadecimal digits. In addition, binary data might be transmitted using some other communication channel, and referenced within the XML data itself using a URI.
Protocols that need a container that can hold both structural data and large quantities of binary data should consider carefully whether XML is appropriate, since the Base64 and hex encodings are inefficient. Otherwise, protocols should use the mechanisms of XML Schema to represent binary data; the Base64 encoding is best for larger quantities of data.
XML does not allow "control" characters (0x00-0x1F) except for TAB (0x09), CR (0x0A), and LF (0x0D). They can not be specified even using character entity references. There is currently no common way of encoding them within what is otherwise ordinary text. This means that strings that might be considered "text" within an ABNF-defined protocol element may need to be treated as binary data within an XML representation, or some other encoding mechanism might need to be invented.
| TOC |
In some situations, it is possible to incrementally process an XML document as each tag is received; this is analogous to the process by which browsers incrementally render HTML pages as they are received. Note that incremental processing is difficult to implement if interspersed across multiple interactions. In other words, if a protocol requires incremental processing across both directions of a bidirectional stream, then it may place an unusual burden on protocol implementers.
| TOC |
In addition to its role as a validity mechanism, an XML DTD provides a facility for "entity declarations" ([8] (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” October 2000.), section 4.2). An entity declaration defines, in the DTD, a kind of macro capability where an "entity reference" may be used to call up and include the content of the entity declaration.
This feature adds complexity to XML processing, and seems more appropriate for use of XML in document processing than in data representation. As such, this document recommends avoiding entity declarations in protocol specifications.
On the other hand, there are five standard entity references built into XML: "&", "<", ">", "'", and """. XML also has the ability to write character data using numeric entity references (using the Unicode [33] (Unicode Consortium, “The Unicode Standard, as it may from time to time be revised or amended,” March 2002.) value for the character). Entity references are normally expanded before the XML Information Set is computed. Restricting the use of these entity references would introduce an additional syntactic restriction (see Section 4.3 (Syntactic Restrictions)) unnecessarily; these entity references should be allowed.
| TOC |
When using XML in the context of a stateless protocol, be it the protocol itself (e.g., SOAP), or simply as content transferred by an existing protocol (e.g., XML/HTTP), care must be taken to not make the meaning of a message depend on information outside the message itself. XML provides external entities (see Section 4.13 (Entity Declarations and Entity References)), which are an easy way to make the meaning of a message depend on something external. Using schema languages that can change the Infoset, like XML Schema, is another way.
| TOC |
The XML Base specification [36] (Marsh, J., “XML Base,” June 2001.) defines an attribute "xml:base" in the XML namespace that is intended to affect the "base" to be used for relative URI processing described in RFC 2396 [17] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax,” August 1998.). The facilities of xml:base for controlling URI processing may be useful to protocol designers, but if xml:base is allowed the interaction with any other protocol facilities for establishing URI context must be specified clearly. Note that use of relative URIs in namespace declarations has been deprecated by the W3C; some specific issues with relative URIs in namespace declarations and canonical XML can be found in section 1.3 of RFC 3076 [6] (Boyer, J., “Canonical XML Version 1.0,” March 2001.).
Note also that, in many cases, the term "URI" and the syntactic use of URIs within XML allows non-ASCII characters within URIs. For example, the XML Schema "anyURI" datatype ([42] (Biron, P. and A. Malhotra, “XML Schema Part 2: Datatypes,” May 2001.) section 3.2.17) allows for direct encoding of characters outside of the US-ASCII range. Most current IETF protocols and specifications do not allow this syntax. Protocol specifications should be clear about the range of characters specified, e.g., by adding a restriction to the range of characters allowed in the anyURI schema datatype, or by specifying that characters outside the US-ASCII range should be escaped when passed to older protocols or APIs.
| TOC |
XML's prescribed white space handling behavior can be a source of confusion between protocol designers and implementers. In XML instances all white space is considered significant and is by default visible to processing applications. Consider this example from Section 4.10 (Element and Attribute Design Considerations):
<address> <addrType><ipv4/></addrType> <value><IP_ADDRESS></value> </address>
This fragment contains an <address> element and two child elements. It also contains white space for pretty-printing purposes:
Implementers might safely assume that they can ignore the white space in the example above, but white space used for pretty-printing can be a source of confusion in other situations. Consider a minor change to the <value> element:
<value> <IP_ADDRESS> </value>
where white space is found on both sides of the IP address. XML processors treat the white space surrounding "<IP_ADDRESS>" as an integral part of the <value> element. A failure to recognize this behavior can lead to confusion and errors in both design and implementation.
All white space is considered significant in XML instances. As a consequence, it is recommended that protocol designers provide specific guidelines to address white space handling within protocols that use XML.
| TOC |
When XML is used in an IETF protocol there are multiple factors that might require IANA action, including:
| TOC |
This section describes internationalization considerations for the use of XML to represent data in IETF protocols. In addition to the recommendations here, IETF policy on the use of character sets and languages described in RFC 2277 [3] (Alvestrand, H., “IETF Policy on Character Sets and Languages,” January 1998.) also applies.
| TOC |
IETF protocols frequently speak of the "character set" or "charset" of a string, which is used to denote both the character repertoire and the encoding used to represent sequences of characters as sequences of bytes.
XML performs all character processing in terms of the Universal Character Set (UCS, [31] (International Organization for Standardization, “Information Technology - Universal Multiple-octet coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane,” May 1993.) and [33] (Unicode Consortium, “The Unicode Standard, as it may from time to time be revised or amended,” March 2002.)). XML requires all XML processors to support both the UTF-8 [4] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” January 1998.) and UTF-16 [20] (Hoffman, P. and F. Yergeau, “UTF-16, an encoding of ISO 10646,” February 2000.) encodings of UCS, although other encodings (charsets) compatible with UCS may be allowed. Documents and external parsed entities encoded in UTF-16 are required to begin with a Byte Order Mark ([8] (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” October 2000.) section 4.3.3).
IETF policy [3] (Alvestrand, H., “IETF Policy on Character Sets and Languages,” January 1998.) requires that the UTF-8 charset be allowed for all text.
This document requires that IETF protocols using XML allow for the UTF-8 encoding of XML data. Since conforming XML processors are mandated to also accept UTF-16 encoding, also allowing for UTF-16 encoding (with the mandated Byte Order Mark) is recommended. Some XML applications are using a Byte Order Mark with UTF-8 encoding, but this use should not be encouraged and isn't appropriate for XML embedded in other protocols.
Restricting XML data to only be expressed in UTF-8 is an additional syntactic restriction (see Section 4.3 (Syntactic Restrictions)) which, depending on circumstances, might add additional implementation complexity. When encodings other than UTF-8 or UTF-16 are used, the encoding must be specified using an "encoding" attribute in the XML declaration (see Section 4.4 (XML Declarations)), even if there might be other protocol mechanisms for designating the encoding.
| TOC |
Text encapsulated in XML can be represented in many different human languages, and it is often useful to explicitly identify the language used to present the text. XML defines a special attribute in the "xml" namespace, xml:lang, that can be used to specify the language used to represent data in an XML document. The xml:lang attribute (which has to be explicitly declared for use within a DTD or XML Schema) and the values it can assume are defined in section 2.12 of [8] (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” October 2000.).
It is strongly recommended that protocols representing data in a human language mandate use of an xml:lang attribute if the XML instance might be interpreted in language-dependent contexts.
| TOC |
There are standard mechanisms in the typography of some human languages that can be difficult to represent using merely XML character string data types. For example, pronunciation clues can be provided using Ruby annotation [39] (Suignard, M., Ishikawa, M., Duerst, M., and T. Texin, “Ruby Annotation,” May 2001.), and embedding controls (such as those described in section 3.4 of [34] (Duerst, M. and A. Freytag, “Unicode in XML and other Markup Languages,” February 2002.)) or an XHTML [40] (Pemberton, S., “XHTML 1.0: The Extensible HyperText Markup Language,” January 2000.) "dir" attribute can be used to note the proper display direction for bidirectional text.
There are a number of tricky issues that can arise when using extended character sets with XML document formats. For example:
Some of these issues are discussed, with recommendations, in the W3C's "Character Model for the World Wide Web" document [44] (Duerst, M., Yergeau, F., Ishida, R., Wolf, M., Freytag, A., and T. Texin, “Character Model for the World Wide Web 1.0,” April 2002.).
It is strongly recommended that protocols representing data in a human language reuse existing mechanisms as needed to ensure proper display of human-legible text.
| TOC |
This memo, per se, has no impact on the IANA. Section 4.17 (Interaction with the IANA) notes some factors that might require IANA action when protocols using XML are defined.
| TOC |
Network protocols face many different kinds of threats, including unintended disclosure, modification, and replay. Passive attacks, such as packet sniffing, allow an attacker to capture and view information intended for someone else. Captured data can be modified and replayed to the original intended recipient, with the recipient having no way to know that the information has been compromised, detect modifications, be assured of the sender's identity, or to confirm which protocol instance is legitimate.
Several security service options for XML are available to help mitigate these risks. Though XML does not include any built-in security services, other protocols and protocol layers provide services that can be used to protect XML protocols. XML encryption [10] (Imamura, T., Dillaway, B., Schaad, J., and E. Simon, “XML Encryption Syntax and Processing,” October 2001.) provides privacy services to prevent unintended disclosure. Canonical XML [6] (Boyer, J., “Canonical XML Version 1.0,” March 2001.) and XML digital signatures [7] (Eastlake, D., Reagle, J., and D. Solo, “(Extensible Markup Language) XML-Signature Syntax and Processing,” March 2002.) provide integrity services to detect modification and authentication services to confirm the identity of the data source. Other IETF security protocols (e.g., the Transport Layer Security (TLS) protocol [2] (Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A., and P. Kocher, “The TLS Protocol Version 1.0,” January 1999.)) are also available to protect data and service endpoints as appropriate. Given the lack of security services in XML, it is imperative that protocol specifications mandate additional security services to counter common threats and attacks; the specific required services will depend on the protocol's threat model.
Experience has shown that code that parses network traffic is often a "soft target" for blackhats. Accordingly, implementers MUST take great care to ensure that their XML handling code is robust with respect to malformed XML, buffer overruns, misuse of entity declarations, and so on.
XML mechanisms that follow external references (Section 4.14 (External References)) may also expose an implementation to various threats by causing the implementation to access external resources automatically. It is important to disallow arbitrary access to such external references within XML data from untrusted sources. Many XML grammars define constructs using URIs for external references; in such cases, the same precautions must be taken.
| TOC |
The authors would like to thank the following people who have provided significant contributions to the development of this document:
Mark Baker, Tim Berners-Lee, Tim Bray, James Clark, Josh Cohen, John Cowan, Alan Crouch, Martin Duerst, Jun Fujisawa, Christian Geuer-Pollmann, Yaron Goland, Graham Klyne, Dan Kohn, Rick Jeliffe, Chris Lilley, Murata Makoto, Michael Mealling, Jean-Jacques Moreau, Andrew Newton, Julian Reschke, Jonathan Rosenberg, Miles Sabin, Rich Salz, Peter Saint-Andre, Simon St Laurent, Margaret Wasserman, and Daniel Veillard.
| TOC |
| TOC |
| TOC |
| [11] | Mealling, M., Masinter, L., Hardie, T., and G. Klyne, “An IETF URN Sub-namespace for Registered Protocol Parameters,” draft-mealling-iana-urn-04 (work in progress), March 2003 (TXT). |
| [12] | Mealling, M., “The IETF XML Registry,” draft-mealling-iana-xmlns-registry-05 (work in progress), June 2003 (TXT). |
| [13] | Case, J., Fedor, M., Schoffstall, M., and J. Davin, “Simple Network Management Protocol (SNMP),” STD 15, RFC 1157, May 1990 (TXT). |
| [14] | Srinivasan, R., “XDR: External Data Representation Standard,” RFC 1832, August 1995 (TXT). |
| [15] | Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” RFC 2045, November 1996 (TXT). |
| [16] | Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” RFC 2234, November 1997 (TXT). |
| [17] | Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax,” RFC 2396, August 1998 (TXT, HTML, XML). |
| [18] | Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 2434, October 1998 (TXT, HTML, XML). |
| [19] | Rose, M., “Writing I-Ds and RFCs using XML,” RFC 2629, June 1999 (TXT, HTML, XML). |
| [20] | Hoffman, P. and F. Yergeau, “UTF-16, an encoding of ISO 10646,” RFC 2781, February 2000 (TXT). |
| [21] | Klensin, J., “Simple Mail Transfer Protocol,” RFC 2821, April 2001 (TXT). |
| [22] | Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, “NFS version 4 Protocol,” RFC 3010, December 2000 (TXT). |
| [23] | Kennedy, H., “Binary Lexical Octet Ad-hoc Transport,” RFC 3252, April 2002 (TXT). |
| [24] | Popp, N., Mealling, M., and M. Moseley, “Common Name Resolution Protocol (CNRP),” RFC 3367, August 2002 (TXT). |
| [25] | Backus, J., “The syntax and semantics of the proposed international algebraic language of the Zurich ACM-GAMM conference,” June 1959. |
| [26] | American National Standards Institute, “Code Extension Techniques for Use with the 7-bit Coded Character Set of American National Standard Code (ASCII) for Information Interchange,” ANSI X3.41, FIPS PUB 35, 1974. |
| [27] | American National Standards Institute, “Information Retrieval: Application Service Definition and Protocol Specification,” ANSI Z39.50, ISO Standard 23950, 1995. |
| [28] | International Organization for Standardization, “Information Processing Systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1),” ISO Standard 8824, December 1990. |
| [29] | International Organization for Standardization, “Information Processing Systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1),” ISO Standard 8825, December 1990. |
| [30] | International Organization for Standardization, “Information processing - Text and office systems - Standard Generalized Markup Language (SGML),” ISO Standard 8879, 1988. |
| [31] | International Organization for Standardization, “Information Technology - Universal Multiple-octet coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane,” ISO Standard 10646-1, May 1993. |
| [32] | International Organization for Standardization, “DSDL Part 0 - Overview,” December 2001. |
| [33] | Unicode Consortium, “The Unicode Standard, as it may from time to time be revised or amended,” March 2002. |
| [34] | Duerst, M. and A. Freytag, “Unicode in XML and other Markup Languages,” February 2002. |
| [35] | Bray, T., Paoli, J., and C. Sperberg-McQueen, “Extensible Markup Language (XML) 1.0,” W3C REC-xml-1998, February 1998. |
| [36] | Marsh, J., “XML Base,” W3C REC-xmlbase, June 2001. |
| [37] | Cowan, J. and R. Tobin, “XML Information Set,” W3C REC-infoset, October 2001. |
| [38] | Lassila, O. and R. Swick, “Resource Description Framework (RDF) Model and Syntax Specification,” W3C REC-rdf-syntax, February 1999. |
| [39] | Suignard, M., Ishikawa, M., Duerst, M., and T. Texin, “Ruby Annotation,” W3C REC-RUBY, May 2001. |
| [40] | Pemberton, S., “XHTML 1.0: The Extensible HyperText Markup Language,” W3C REC-XHTML, January 2000. |
| [41] | Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, “XML Schema Part 1: Structures,” W3C REC-xmlschema-1, May 2001. |
| [42] | Biron, P. and A. Malhotra, “XML Schema Part 2: Datatypes,” W3C REC-xmlschema-2, May 2001. |
| [43] | Clark, J., “XSL Transformations (XSLT) Version 1.0,” W3C REC-xslt, November 1999. |
| [44] | Duerst, M., Yergeau, F., Ishida, R., Wolf, M., Freytag, A., and T. Texin, “Character Model for the World Wide Web 1.0,” April 2002. |
| [45] | Gudgin, M., Hadley, M., Moreau, JJ., and H. Nielsen, “SOAP Version 1.2 Part 1: Messaging Framework,” June 2002. |
| [46] | Gudgin, M., Hadley, M., Moreau, JJ., and H. Nielsen, “SOAP Version 1.2 Part 2: Adjuncts,” June 2002. |
| [47] | W3C Communications Team, “XML in 10 points,” November 2001. |
| [48] | OASIS Technical Committee: RELAX NG, “RELAX NG Specification,” December 2001. |
| [49] | Jelliffe, R., “The Schematron,” November 2001. |
| TOC |
| Scott Hollenbeck | |
| VeriSign, Inc. | |
| 21345 Ridgetop Circle | |
| Dulles, VA 20166-6503 | |
| US | |
| Phone: | +1<PHONE_NUMBER> |
| Email: |<EMAIL_ADDRESS>|
| Marshall T. Rose | |
| Dover Beach Consulting, Inc. | |
| POB 255268 | |
| Sacramento, CA 95865-5268 | |
| US | |
| Phone: | +1<PHONE_NUMBER> |
| Email: |<EMAIL_ADDRESS>|
| Larry Masinter | |
| Adobe Systems Incorporated | |
| Mail Stop W14 | |
| 345 Park Ave. | |
| San Jose, CA 95110 | |
| US | |
| Phone: | +1<PHONE_NUMBER> |
| Email: |<EMAIL_ADDRESS>|
| URI: | http://larry.masinter.net |
| TOC |
Copyright © The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Funding for the RFC Editor function is currently provided by the Internet Society.


I'm a hot waifu Discord bot based on ゼロツー (Zero Two) from ダーリン・イン・ザ・フランキス (Darling in the FranXX)
I serve a variety of needs and have tons of functionality + features
AI-Powered Chatbot! Just mention: @Zero Two#5534
Interact with tons of services you already love (ie. AniList, Osu!, League, etc.)
guilds
users
voice channels
with 🍯
Need your help to speak more languages!
Add some more languages, or contribute to the development.
If you got some programming know-how (JavaScript), you could help make this bot even better.
View the project on
GitHub
It costs my own pocket money to support and maintain this bot.
My goal for this project is to provide greatness for the community.
If this bot grows and grows, trying to maintain it will likely be difficult.
Sorry to those that might expect a reward, but all I can provide to you is gratitude if you do decide to donate.
Or help by contributing to the project (see above).
Or not because it's a free service, but it would be really awesome if you helped to support the ongoing maintenance and development of the project.
DONATE
Discord: @pinnouse#7766
Email<EMAIL_ADDRESS>Twitter: @pinnouse
GitHub: pinnouse


|
With the explosive growth of mobile phone ownership – more than 40% of the UK
population now owns a mobile phone – the link between two of today’s hottest technologies
is expected to create a potent cocktail.
In only a couple of years, new telecoms networks that support high-speed mobile internet access will be in place and internet-enabled phones are expected to be the norm. By 2004, Forrester Research predicts that one-third of Europeans will regularly access the internet via their mobile phones. Wireless Application Protocol (WAP) The standard for connecting wireless devices such as phones to the internet. Short Message Service (SMS) Allows text messages of up to 160 characters to be sent to and from mobile phones. Global System for Mobile Communications (GSM) The prevailing mobile standard in Europe and most of Asia Pacific. General Packet Radio Service (GPRS) Standard within GSM that will allow instant, high-speed internet access from mobile devices. European mobile phone networks will begin to introduce GPRS in the second half of 2000. Universal Mobile Telecommunications System/Third Generation (UMTS/3G) High-capacity, third generation network that will support mobile video as well as audio, graphics and text. The first UMTS licence has been awarded in Finland and the rest of Europe will start to award licences this year. |


Over the last decade, the advent of high-throughput sequencing techniques brought an exponential growth in biosequence database sizes. With increased throughput demand and popularity of computational biology tools, reducing time-to-solution during computational analysis has become a significant challenge in the path to scientific discovery.
Conventional computer architecture is proven to be inefficient for computational biology and bioinformatics tasks. For example, aligning even several hundred DNA or protein sequences using progressive multiple alignment tools consumes several CPU hours on high performance computer. Hence, computational biology and bioinformatics rely on hardware accelerators to allow processing to keep up with the increasing amount of data generated from biology applications.
In a typical application, dominant portion of the runtime is spent in a small number of computational kernels, making it an excellent target for hardware acceleration. The combination of increasingly large datasets and high performance computing requirements make computational biology prime candidate to benefit from accelerator architecture research. Potential directions include 3D integration, near-data processing, automata processing, associative processing and reconfigurable architectures.
| 8:15 - 8:20 | Opening Remarks |
| 8:20 - 9:20 | Keynote 1: William (Bill) Dally, Stanford & NVIDIA
"Hardware Enabled Biology" (slides) |
| 9:20 - 9:40 | Sahand Kashani, Stuart Byma and James Larus (EPFL)
"IMPACT: Interval-based Multi-pass Proteomic Alignment with Constant Traceback" (slides) |
| 9:40 - 10:00 | Damla Senol Cali, Jeremie S. Kim, Saugata Ghose, Can Alkan and Onur Mutlu
"Nanopore Sequencing Technology and Tools for Genome Assembly: Computational Analysis of the Current State, Bottlenecks and Future Directions" (slides) |
| 10:00 - 10:30 | Coffee break |
| 10:30 - 11:20 | Invited Talk: Ananth Kalyanaraman, WSU
"Scaling Graph Applications in Computational Biology" |
| 11:20 - 11:40 | Xueqi Li (UCSB, KITS)
"Scalable In-Memory System for Genomic Analysis" |
| 11:40 - 12:00 | Meysam Roodi, Zahra Lak and Andreas Moshovos (Univ. of Toronto)
"Accelerating GATK Variant Calling HaplotypeCaller Tool" |
| 12:00 - 13:30 | Lunch |
| 13:30 - 14:30 | Keynote 2: Onur Mutlu, ETH & CMU
“Accelerating Genome Analysis: A Primer on an Ongoing Journey” (slides, video) |
| 14:30 - 14:50 | Jeremie Kim, Damla Senol, Hongyi Xin, Donghyuk Lee, Saugata Ghose, Mohammed Alser, Hasan Hassan, Oguz Ergin, Can Alkan and Onur Mutlu
"GRIM-filter: fast seed filtering in read mapping using emerging memory technologies" |
| 14:50 - 15:10 | Roman Kaplan, Leonid Yavits and Ran Ginsar (Technion, Israel Institute of Technology)
"RASSA: Resistive Pre-Alignment Accelerator for Approximate DNA Long Read Mapping" (slides, video) |
| 15:10 - 15:40 | Coffee break |
| 15:40 - 16:00 | Wenqin Huangfu, Shuangchen Li, Xing Hu and Yuan Xie (UCSB)
"RADAR: A 3D-ReRAM based DNA Alignment Accelerator Architecture" |
| 16:00 - 16:20 | Zheming Jin and Hal Finkel (ANL)
"Exploring the Random Network of Hodgkin and Huxley Neurons with Exponential Synaptic Conductances on OpenCL FPGA Platform" |
| 16:20 - 16:40 | Meysam Roodi, Zahra Lak and Andreas Moshovos (Univ. of Toronto)
"Improving BWA-MEM performance" |
| 16:40 - 16:45 | Closing remarks |
Talk abstract:
Genome analysis is the foundation of many scientific and medical discoveries as well as a key pillar of personalized medicine.
Any analysis of a genome fundamentally starts with the reconstruction of the genome from its sequenced fragments.
This process is called read mapping.
One key goal of read mapping is to find the variations that are present between the sequenced genome and reference genome(s) and to tolerate the errors introduced by the genome sequencing process.
Read mapping is currently a major bottleneck in the entire genome analysis pipeline because state-of-the-art genome sequencing technologies are able to sequence a genome much faster than the computational techniques that are employed to reconstruct the genome.
New sequencing technologies, like nanopore sequencing, greatly exacerbate this problem while at the same time making genome sequencing much less costly.
This talk describes our ongoing journey in greatly improving the
performance of genome read mapping. We first provide a brief
background on read mappers that can comprehensively find variations
and tolerate sequencing errors. Then, we describe both algorithmic and
hardware-based acceleration approaches. Algorithmic approaches exploit
the structure of the genome as well as the structure of the underlying
hardware. Hardware-based acceleration approaches exploit specialized
microarchitectures or new execution paradigms like processing in
memory. We show that significant improvements are possible with both algorithmic and hardware-based approaches and their combination.
We conclude with a foreshadowing of future challenges brought about by very low cost yet highly error prone new sequencing technologies.
<EMAIL_ADDRESS>Short bio: Leonid received his MSc and PhD in Electrical Engineering from the Technion. After graduating, he co-founded VisionTech where he co-designed a single chip MPEG2 codec. Following VisionTech’s acquisition by Broadcom, he co-founded Horizon Semiconductors where he co-designed a Set Top Box on chip for cable and satellite TV.
Leonid is a postdoc fellow in Electrical Engineering in the Technion. He co-authored a number of patents and research papers on SoC and ASIC. His research interests include non von Neumann computer architectures and processing in memory
<EMAIL_ADDRESS>Short bio:
Roman received his BSC and MSc from the faculty of Electrical Engineering, Technion, Israel in 2009 and 2015, respectively. He is now a PhD candidate in the same faculty under the supervision of Prof. Ran Ginosar.
Roman's research interests are parallel computer architectures, in-data processing, accelerators for machine learning and big data, and novel computer architectures for bioinformatics applications.


Pay with Amazon PHP Sample Code
Click
here
to create a new order reference before running one of the samples below
Simple checkout
Split shipments
Refund
Cancellation


What is a pandemic? We have read about pandemics only in books or heard stories related
to it from our grandparents. Plague influenza, small pox, these diseases had affected
the lives of our ancestors. Now for the first time we are experiencing a pandemic of
such a huge scale. The corona virus which is so tiny, that cannot be seen with our naked
eyes has taken the whole world in a storm. Maybe the pandemic might have not spread like
wild fire if people had behaved responsibly, mujhe kaise hoga, mujhe toh nahi hoga this
attitude of people has hit many. During these times a little fear is better than being
too brave.
Humans have always felt that they had conquered everything under the sun. But God had
other plans, the virus has shown us that we after so many inventions and discoveries are
still so vulnerable and have achieved so little. You and me have taken the life so
casually until a few months back, but now we have to go slow. We start feeling scared in
a crowd, start doubting if a person just sneezes as many are terrified by this deadly
disease. The government is trying it’s best to control the pandemic and trying to make
vaccines to eradicate this virus. We all are waiting for that day when this would
happen. Narendra Modi had said in his speech that we would go back around 2 decades if
this pandemic overpowered us.The pandemic is not only corroding human lives but also
affecting the economic growth. Number of people have lost their jobs. The worst state
was of the migrant workers. The fear of this disease has led to psychological problems
in many. Going to a friend’s house, eating out, going for a movie, stroll in the park or
for that matter having road side pani puri is now feeling like a luxury because it now
feels out of reach. I like the government concept of my home my family. If each family
follows the simple rules, we can keep this virus away from our doorstep.
The virus which entered our lives in the beginning of 2020, hope it leaves our lives
permanently at the wake of year 2021. In the end I would like to say stay mask, stay
safe and stay home.
“Hello” (disturbance in the background due to heavy rain and train siren)
“Nikla Kya?”
“Han pohonch hi raha hun.”
“8:28 na?”
“Han 8:28.”
What is your greatest struggle in life?
Monsoons have their own pros and cons, brings life somewhere and destroys elsewhere, but
then that’s how the system works. Conservation of matter.
What are we doing in life these days, we wake up every day to routine life, the same
commute, the same people, the same way back home. What have you done different rather
than attaching yourself to this monotony. We perceive everything in colour yet live a
monochrome life, how different is that?
We name our days, our months, but what have we done new to remember that day by name?
how have we lived till now.

Ask me and I’ll say the cheapest way to travel to south Bombay is by a local. Always
cheapest, never comfortable enough until you get used to it. The first time I probably
travelled on train alone would be the first day of college. Always hated them, because I
never had the opportunity to be a part of them…
Hey man! How do you get to Mahim?
What would I answer, I had to figure that out myself?
When you are new to something, everything seems tough, but time does all the work for
you.
Two years have gone by and ask me now, I can tell you the platform the train would be at
Mahim, where you would find TC’s and where you’d find none. How to travel without a
ticket, or at which station the TC would get on. Why do I know all this?
Did I have the intent of learning? This was something life taught me, among many other
things.
“Churchgate jane vali bara dibbo ki dheemi local, platform no 2 par aa rahi hai!!”
Would always make me rush, in a hurry to get that second last first-class carriage.
Sometimes waiting for a friend, I would sit at a bench between the platform, and watch
all those people whirl by.
Always felt my time slowed down. Where were they headed? Who were they? Do we all have
the same algorithms or can we alter the codes?
How well can you dance to the symphony of life? Or can you change the symphony to match
your moves?
The 20-minute commute from Andheri to Mahim has witnessed the craziest conspiracies,
weirdest conversations and the most beautiful moments of life and some good friends.
Rains always messed everything up, but they never failed to create a wonderful feeling
inside of you.
The long unending wait before Khar station always messes up schedules, waiting in hopes
for the train to move.
A constant group of people, never fail to board the 8:28 ST at platform 2. Always in
their same seats, the same people, the same coach always on time.
“Bro…Lecture baithna hai kya?”
“Vapis ghar chale?”

I always wondered how life would be if I were in a different college.
Going back home was tedious.
An increase in frequency of trains to platform no 1 at Borivali would be appreciated.
Local to Andheri is quite unpredictable.
“Wakt kaise guzar gaya kabhi pata hi nahi chala, Na jane kuch sapne, sapne hi reh gaye.”
“Bro? kal 8:28 na?”
“Han 8:28.”


video stay-on-screen (nft)
works with
this image
Video (c) copyright 2008, Blender Foundation / www.bigbuckbunny.org
Source code
here
REPOSITION VIDEO
Loading, please wait...


Welsh rugby set for massive £35million windfall from CVC investment in Guinness PRO14
News of the cash boost was revealed at the Welsh Rugby Union’s AGM
by Simon ThomasWelsh rugby is set for a massive £35million cash injection as a result of CVC investing in the Guinness PRO14.
Private equity firm CVC have agreed a deal in principle to buy a 27 per cent share in the cross-border competition for around £120m.
That follows a similar investment arrangement with England’s Gallagher Premiership, which has received more than £200m.
The PRO14 is owned by the three Celtic Unions - Wales, Ireland and Scotland - so the lion's share of the money from CVC would go to them, with sides from South Africa and Italy also benefitting.
That would see as much as £35m coming into the Welsh game as a one-off payment.
Under the investment deal, which has been in discussion for a number of months, 27 per cent of the tournament’s income would be passed on to CVC each year.
It will lead to mounting speculation about the possibility of a British & Irish League being set up, as CVC look to maximise their investment in the two existing competitions.
News of the impending cash boost was revealed at the Welsh Rugby Union’s Annual General Meeting at the Principality Stadium today.
Speaking after the meeting, WRU chairman Gareth Davies said: “Private equity have invested into the Gallagher Premiership in England, which has obviously created a lot of interest.
“There’s almost a natural progression to look at the PRO14, I suppose.
“Discussions are ongoing and and it looks as though that could be moving forward.
“That would see an inflow of money into Ireland, Scotland and Wales, which is obviously well received.
“Hopefully there will be some extra funds flowing into our coffers.
“The money will come into the Union first of all.
“In England, it’s just gone directly to the clubs, because they were the ones negotiating.
“We are in discussion with the regions and they will obviously benefit, as will other aspects of the game.
“The regions will benefit, while some of that money will go to the community game and potentially the women’s game, as we have many hungry mouths to feed.”
On the principle of such a deal, Davies said: “We are not selling part of the Unions, we are selling a competition, the commercial arm of the competition.
“The game itself, the rugby element, will still be controlled by the Unions and the professional teams.
“It’s an interesting departure and development. Rugby isn’t always good at working together, in terms of the best results, because there are lots of areas of self-interest.
“So it probably needs an external partner to come in and knock heads together in many respects and to more commercialise what is probably regarded as an under-exploited sport in terms of commercialism.”
Celtic Rugby, who own the PRO14, have tonight issued the following statement on the subject.
It reads: "Celtic Rugby and its shareholders can confirm that a request has been filed to the Irish Competition and Consumer Protection Commission for Merger and Acquisition clearance by CVC Capital Partners.
"The request has been made in relation to a potential transaction involving Celtic Rugby and CVC Capital Partners.
"Both parties are involved in advanced discussions and until those talks have been finalised there will be no further comment."
In another development from today’s AGM, it’s been revealed that Liza Burgess will become the first woman to be elected to the WRU board by the member clubs in its 138-year history.
Former Wales player and coach Burgess, who won 87 caps, joined the WRU Council at the AGM after winning recent club elections.
And she is now the only candidate standing for the position of WRU director on the board, a post vacated by the retiring Anthony Buchanan.
She will be formally elected as a WRU director next Tuesday at a meeting chaired by new WRU president Gerald Davies.
Former Wales and Lions winger Davies is taking over from Dennis Gethin, who bowed out at the AGM after 12 years in the role.


Looking Ahead
Lookahead specifies a pattern to be matched but not returned. A lookahead is actually a subexpression and is formatted as such. The syntax for a lookahead pattern is a subexpression preceded by ?=, and the text to match follows the = sign.
Tip | Some regular expression documentation uses the term consume to refer to what is matched and returned; lookahead matches are said to not consume. |
Here is an example. The following text contains a list of URLs, and you need to extract the protocol portion of each (possibly so as to know how to process them). Here's the example:
http://www.forta.com/
https://mail.forta.com/
ftp://ftp.forta.com/
.+(?=:)
http://www.forta.com/
https://mail.forta.com/
ftp://ftp.forta.com/
In the URLs listed, the protocol is separated from the hostname by a :. Pattern .+ matches any text (http in the first match), and subexpression (?=:) matches :. But notice that the : was not matched; ?= tells the regular expression engine to match : but to lookahead (and not consume it).
To better understand what ?= is doing, here is the same example, this time without the lookahead metacharacters:
http://www.forta.com/
https://mail.forta.com/
ftp://ftp.forta.com/
.+(:)
http://www.forta.com/
https://mail.forta.com/
ftp://ftp.forta.com/
The subexpression (:) correctly matches :, but the matched text is consumed and is returned as part of the match.
The difference between the two examples is that the former used pattern (?=:) to match the :, and the latter used (:). Both of these patterns matched the same thing; they both matched the : after the protocol. The difference is in whether the matched : was actually included in the matched text. When using lookahead, the regular expression parser looks ahead to process the : match, but does not process it as part of the primary search. .+(:) finds the text up to and including the :. .+(?=:) finds the text up to, but not including, the :.
Note | Lookahead (and lookbehind) matches actually do return results, but the results are always 0 characters in length. As such, you will sometimes find the lookaround operations referred to as being zero-width. |
Tip | Any subexpression can be turned into a lookahead expression by simply prefacing the text with ?=. Multiple lookahead expressions may be used in a search pattern, and they may appear anywhere in the pattern (not just at the beginning, as shown here). |
|


2 references to GetAssemblies
System.Management.Automation (2)
engine\parser\TypeResolver.cs (2)
380
var assemList = assemblies ?? ClrFacade.
GetAssemblies
(typeResolutionState, typeName);
404
assemList = ClrFacade.
GetAssemblies
(typeResolutionState, newTypeName);


WATCHERS REBORN (1998) A film review by Justin Felix. Copyright 1999 Justin Felix. All of my film reviews are archived at http://us.imdb.com/M/reviews_by?Justin+Felix This review also appears in the Shrubbery at http://www.theshrubbery.prohosting.com/0299/movie3.html
Rating: *1/2 (out of five)
Screenplay by Sean Dash. Based upon the novel WATCHERS by Dean Koontz. Directed by John Carl Buechler. Starring Mark Hamill, Lou Rawls, Kane Hodder, Lisa Wilcox. Rated R (contains violence and profanity) 83 mins.
Synopsis: A humorless police officer's life changes when he befriends a super-smart, super-adorable golden retriever named Einstein and a cute, young blond scientist.  Meanwhile, a group of white, chain-smoking, gun-toting NSA agents in sunglasses and business suits tries to kill all the other characters in the movie.
Comments: WATCHERS REBORN, a cheaply made direct-to-video turkey, is the fourth sequel to the first film version of Dean Koontz's bestselling novel WATCHERS. Technically, this should have been called WATCHERS V, but it seems that this cycle of horror movies, much like many other sequel-crazy film series, has decided to drop the numbers from the titles. (Even the Star Trek movies dropped the numbers from their titles after STAR TREK VI.) The makers of WATCHERS REBORN probably want to fool unsuspecting video rental customers into thinking this might be a good movie instead of a crappy fifth installment of a film series which should have died a long time ago.
This really isn't a good movie. Have you ever rented a movie and recieved a sinking feeling about it when you watched the previews preceding the feature presentation? Well, any hope a viewer may have had, perhaps because he is a fan of novelist Dean Koontz or actor Mark Hamill, will be dashed by the time he's seen the trailers tagged on before the beginning of WATCHERS REBORN. They're awful.  Scott Baio!
After surviving these abysmal trailers, the person finally gets to watch the movie he rented: WATCHERS REBORN. "Maybe it won't be *that* bad" he may say to himself. "Perhaps, just perhaps, the bottom-of-the-barrel film fluff advertised before it is greatly misleading. WATCHERS REBORN, after all, is based on that cool book Dean Koontz wrote a decade ago. It stars Mark Hamill -- Luke Skywalker himself from that terrific STAR WARS trilogy. Lou Rawls is even in the mix!"
Unfortunately, the Force is certainly no longer with Mark Hamill (he looks very sick here), and this movie shares only basic plot elements with WATCHERS, the book. The latter is really too bad. Koontz is a hack writer producing way too many thrillers for his own good, but he is still my favorite hack writer. Koontz has a writing style which is succinct and suspenseful. People who read many of his books, however, often complain of repetitive plot devices. It's definately not a Koontz book if there isn't (1) a psychic, (2) a super-intelligent dog, or (3) a psychotic killer who likes ripping out people's eyeballs. WATCHERS has all three devices, which may explain why it's arguably the most popular of Koontz's books. The idea behind Koontz's novel, though highly implausible, is very interesting.  Silly but kind of neat too.
I'm sorry. I don't mean to ramble on about matters not directly linked to WATCHERS REBORN, the movie. I suppose I just don't want to talk about the movie itself. This turkey is really cheesy. No one in this movie can act, including Mark Hamill, and it's difficult seeing the aged Luke Skywalker stumble around trying to be the hero. The cheese factor is only increased when he's involved in an implied sex scene with the blond biologist / geneticist / zoologist / whatever-the-f**k-she's-supposed-to-be whom he befriends. Mercifully, the filmmakers opted not to do nudity. To be honest, the only half-convincing actor in the film is the golden retriever who plays Einstein. You know a movie is bad when a dog outacts all of its human counterparts.
I find it difficult to relate how laughable the action sequences are in this movie. And the creature! Yes, the creature out after poor Einstein is some guy in a furry suit and a mask which poorly imitates the werewolves in THE HOWLING. This creature is shot about 500,000 times, but it's okay.  Oh, he can also rip body parts off, allowing for many scenes of fake hands and arms being thrown around. Cheesy gore. That's another main element of WATCHERS REBORN. It has many bloody scenes which are thoroughly unconvincing and only increase the film's campiness rather than its suspense.
Ultimately, I gave WATCHERS REBORN a star and a half because bad horror / sci-fi film buffs may get a few kicks out of the film's silliness (though this film will tax even their patience -- it's an 83 minute film, but it feels like four hours). Also, I hate to admit, I have survived far worse than this. Anyone who has sat through the Christopher Lambert and Natasha Henstridge debacle known as ADRENALIN: FEAR THE RUSH will know what I mean. Finally, I couldn't help but think that WATCHERS REBORN would work well as "bot fodder" for the creative folks behind one of my all-time favorite shows, "Mystery Science Theater 3000." This thought alone helped me survive WATCHERS REBORN with a smile on my face.
Rated R, WATCHERS REBORN contains dozens of blood-spattered bodies and unconvincing gore. It also has violence, obviously. I wouldn't recommend it for the little kids, but I'm sure even young teens would make it through this movie okay. Instead of watching this film, however, I recommend reading Koontz's book. Trust me, it'll be time much, much better spent.
Review written January 14, 1999.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


The uvm_link_base class, and its extensions, are provided as a mechanism to allow for compile-time safety when trying to establish links between records within a uvm_tr_database.
| UVM Links | The uvm_link_base class, and its extensions, are provided as a mechanism to allow for compile-time safety when trying to establish links between records within a uvm_tr_database. |
| uvm_link_base | The uvm_link_base class presents a simple API for defining a link between any two objects. |
| uvm_parent_child_link | The uvm_parent_child_link is used to represent a Parent/Child relationship between two objects. |
| uvm_cause_effect_link | The uvm_cause_effect_link is used to represent a Cause/Effect relationship between two objects. |
| uvm_related_link | The uvm_related_link is used to represent a generic “is related” link between two objects. |
The uvm_link_base class presents a simple API for defining a link between any two objects.
Using extensions of this class, a uvm_tr_database can determine the type of links being passed, without relying on “magic” string names.
virtual function void do_establish_link(uvm_link_base link); uvm_parent_child_link pc_link; uvm_cause_effect_link ce_link; if ($cast(pc_link, link)) begin // Record the parent-child relationship end else if ($cast(ce_link, link)) begin // Record the cause-effect relationship end else begin // Unsupported relationship! end endfunction : do_establish_link
| uvm_link_base | ||||
| The uvm_link_base class presents a simple API for defining a link between any two objects. | ||||
| Class Hierarchy | ||||
| ||||
| Class Declaration | ||||
| ||||
| new | Constructor | |||
| Accessors | ||||
| set_lhs | Sets the left-hand-side of the link | |||
| get_lhs | Gets the left-hand-side of the link | |||
| set_rhs | Sets the right-hand-side of the link | |||
| get_rhs | Gets the right-hand-side of the link | |||
| set | Convenience method for setting both sides in one call. | |||
| Implementation Callbacks | ||||
| do_set_lhs | Callback for setting the left-hand-side | |||
| do_get_lhs | Callback for retrieving the left-hand-side | |||
| do_set_rhs | Callback for setting the right-hand-side | |||
| do_get_rhs | Callback for retrieving the right-hand-side |
function void set_lhs( uvm_object lhs )
Sets the left-hand-side of the link
Triggers the do_set_lhs callback.
function uvm_object get_lhs()
Gets the left-hand-side of the link
Triggers the do_get_lhs callback
function void set_rhs( uvm_object rhs )
Sets the right-hand-side of the link
Triggers the do_set_rhs callback.
function uvm_object get_rhs()
Gets the right-hand-side of the link
Triggers the do_get_rhs callback
function void set( uvm_object lhs, rhs )
Convenience method for setting both sides in one call.
Triggers both the do_set_rhs and do_set_lhs callbacks.
pure virtual function void do_set_lhs( uvm_object lhs )
Callback for setting the left-hand-side
pure virtual function void do_set_rhs( uvm_object rhs )
Callback for setting the right-hand-side
pure virtual function uvm_object do_get_rhs()
Callback for retrieving the right-hand-side
The uvm_parent_child_link is used to represent a Parent/Child relationship between two objects.
| uvm_parent_child_link | |||||
| The uvm_parent_child_link is used to represent a Parent/Child relationship between two objects. | |||||
| Class Hierarchy | |||||
| |||||
| Class Declaration | |||||
| |||||
| new | Constructor | ||||
| get_link | Constructs a pre-filled link | ||||
| Implementation Callbacks | |||||
| do_set_lhs | Sets the left-hand-side (Parent) | ||||
| do_get_lhs | Retrieves the left-hand-side (Parent) | ||||
| do_set_rhs | Sets the right-hand-side (Child) | ||||
| do_get_rhs | Retrieves the right-hand-side (Child) |
function new( string name = "unnamed-uvm_parent_child_link" )
Constructor
| name | Instance name |
static function uvm_parent_child_link get_link( uvm_object lhs, uvm_object rhs, string name = "pc_link" )
Constructs a pre-filled link
This allows for simple one-line link creations.
my_db.establish_link(uvm_parent_child_link::get_link(record1, record2));
| lhs | Left hand side reference |
| rhs | Right hand side reference |
| name | Optional name for the link object |
The uvm_cause_effect_link is used to represent a Cause/Effect relationship between two objects.
| uvm_cause_effect_link | |||||
| The uvm_cause_effect_link is used to represent a Cause/Effect relationship between two objects. | |||||
| Class Hierarchy | |||||
| |||||
| Class Declaration | |||||
| |||||
| new | Constructor | ||||
| get_link | Constructs a pre-filled link | ||||
| Implementation Callbacks | |||||
| do_set_lhs | Sets the left-hand-side (Cause) | ||||
| do_get_lhs | Retrieves the left-hand-side (Cause) | ||||
| do_set_rhs | Sets the right-hand-side (Effect) | ||||
| do_get_rhs | Retrieves the right-hand-side (Effect) |
function new( string name = "unnamed-uvm_cause_effect_link" )
Constructor
| name | Instance name |
static function uvm_cause_effect_link get_link( uvm_object lhs, uvm_object rhs, string name = "ce_link" )
Constructs a pre-filled link
This allows for simple one-line link creations.
my_db.establish_link(uvm_cause_effect_link::get_link(record1, record2));
| lhs | Left hand side reference |
| rhs | Right hand side reference |
| name | Optional name for the link object |
The uvm_related_link is used to represent a generic “is related” link between two objects.
| uvm_related_link | |||||
| The uvm_related_link is used to represent a generic “is related” link between two objects. | |||||
| Class Hierarchy | |||||
| |||||
| Class Declaration | |||||
| |||||
| new | Constructor | ||||
| get_link | Constructs a pre-filled link | ||||
| Implementation Callbacks | |||||
| do_set_lhs | Sets the left-hand-side | ||||
| do_get_lhs | Retrieves the left-hand-side | ||||
| do_set_rhs | Sets the right-hand-side | ||||
| do_get_rhs | Retrieves the right-hand-side |
static function uvm_related_link get_link( uvm_object lhs, uvm_object rhs, string name = "ce_link" )
Constructs a pre-filled link
This allows for simple one-line link creations.
my_db.establish_link(uvm_related_link::get_link(record1, record2));
| lhs | Left hand side reference |
| rhs | Right hand side reference |
| name | Optional name for the link object |
The uvm_link_base class presents a simple API for defining a link between any two objects.
virtual class uvm_link_base extends uvm_object
The uvm_tr_database class is intended to hide the underlying database implementation from the end user, as these details are often vendor or tool-specific.
virtual class uvm_tr_database extends uvm_object
The uvm_parent_child_link is used to represent a Parent/Child relationship between two objects.
class uvm_parent_child_link extends uvm_link_base
The uvm_cause_effect_link is used to represent a Cause/Effect relationship between two objects.
class uvm_cause_effect_link extends uvm_link_base
The uvm_related_link is used to represent a generic “is related” link between two objects.
class uvm_related_link extends uvm_link_base
The uvm_void class is the base class for all UVM classes.
virtual class uvm_void
The uvm_object class is the base class for all UVM data and hierarchical classes.
virtual class uvm_object extends uvm_void
Constructor
function new( string name = "unnamed-uvm_link_base" )
Sets the left-hand-side of the link
function void set_lhs( uvm_object lhs )
Gets the left-hand-side of the link
function uvm_object get_lhs()
Sets the right-hand-side of the link
function void set_rhs( uvm_object rhs )
Gets the right-hand-side of the link
function uvm_object get_rhs()
Convenience method for setting both sides in one call.
function void set( uvm_object lhs, rhs )
Callback for setting the left-hand-side
pure virtual function void do_set_lhs( uvm_object lhs )
Callback for retrieving the left-hand-side
pure virtual function uvm_object do_get_lhs()
Callback for setting the right-hand-side
pure virtual function void do_set_rhs( uvm_object rhs )
Callback for retrieving the right-hand-side
pure virtual function uvm_object do_get_rhs()
Constructor
function new( string name = "unnamed-uvm_parent_child_link" )
Constructs a pre-filled link
static function uvm_parent_child_link get_link( uvm_object lhs, uvm_object rhs, string name = "pc_link" )
Sets the left-hand-side (Parent)
virtual function void do_set_lhs( uvm_object lhs )
Retrieves the left-hand-side (Parent)
virtual function uvm_object do_get_lhs()
Sets the right-hand-side (Child)
virtual function void do_set_rhs( uvm_object rhs )
Retrieves the right-hand-side (Child)
virtual function uvm_object do_get_rhs()
Constructor
function new( string name = "unnamed-uvm_cause_effect_link" )
Constructs a pre-filled link
static function uvm_cause_effect_link get_link( uvm_object lhs, uvm_object rhs, string name = "ce_link" )
Sets the left-hand-side (Cause)
virtual function void do_set_lhs( uvm_object lhs )
Retrieves the left-hand-side (Cause)
virtual function uvm_object do_get_lhs()
Sets the right-hand-side (Effect)
virtual function void do_set_rhs( uvm_object rhs )
Retrieves the right-hand-side (Effect)
virtual function uvm_object do_get_rhs()
Constructor
function new( string name = "unnamed-uvm_related_link" )
Constructs a pre-filled link
static function uvm_related_link get_link( uvm_object lhs, uvm_object rhs, string name = "ce_link" )
Sets the left-hand-side
virtual function void do_set_lhs( uvm_object lhs )
Retrieves the left-hand-side
virtual function uvm_object do_get_lhs()
Sets the right-hand-side
virtual function void do_set_rhs( uvm_object rhs )
Retrieves the right-hand-side
virtual function uvm_object do_get_rhs()