text:
Copyright © 2002-2003 W3C ® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.
The World Wide Web is a networked information system. Web Architecture consists of the requirements, constraints, principles, and choices that influence the design of the system and the behavior of agents within the system. When Web Architecture is followed, the large-scale effect is that of an efficient, scalable, shared information space. The organization of this document reflects the three divisions of Web architecture: identification, representation, and interaction. This document also addresses some non-technical (social) issues that play a role in building the shared information space.
This document strives to establish a reference set of requirements, constraints, principles, and design choices for Web architecture.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This document has been developed by W3C's Technical Architecture Group (TAG) (charter).
This draft is an Editor's Draft and some new content has not yet been reviewed by the TAG. The primary changes in this draft were editorial changes based on some comments from Stuart Williams, and the addition of a note regarding the phrase "on the Web" based on comments from David Orchard. A complete list of changes since the previous Working Draft is available on the Web.
This draft remains incomplete; sections 1, 2, and 3 are the most developed; 4 the least. The TAG has published a number of findings that address specific architecture issues. Parts of those findings may appear in subsequent drafts. Please also consult the list of issues under consideration by the TAG.
This draft includes some editorial notes and also references to open TAG issues. These do not represent all open issues in the document. They are expected to disappear from future drafts.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than "work in progress."
The latest information regarding patent disclosures related to this document is available on the Web. As of this publication, there are no disclosures.
Please send comments on this document to the public W3C TAG mailing list email@example.com (archive).
A list of current W3C Recommendations and other technical documents can be found at the W3C Web site.
Highlighted entries in this table of contents link to principles, constraints, good practice notes, and design choices emphasized in the document.
The World Wide Web (or, Web) is a networked information system consisting of agents (programs acting on behalf of a person, entity, or process) that exchange information. Here's a simple travel scenario illustrating a common Web interaction:
" in a glossy travel
magazine. Dan has enough experience with the Web to recognize that
is a URI. He can expect
that the URI should allow him to access relevant weather information.weather.example.com
.This scenario illustrate the three architectural divisions of the Web that are discussed in this document:
.Editor's note: Todo: Introduce notions of client and server. Relation of client to agent and user agent. Relation of server to resource owner.
The intended audience for this document includes:
This document is designed to balance the value of brevity and precision with the value of illustrative examples. TAG findings provide more background, motivation, and examples.
Readers will benefit from familiarity with the Requests for Comments (RFC) series from the IETF, some of which define pieces of the architecture discussed in this document.
The architecture described in this document is principally the result of experience. There has been some theoretical and modeling work in the area of Web Architecture, notably Roy Fielding's work on "Representational State Transfer" [REST].
The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used in accordance with RFC 2119 [RFC2119].
Throughout this document, we elaborate on the travel scenario to introduce and illustrate architectural principles.
Editor's note: The scenario has not yet been well-integrated into sections 3 and 4.
This document focuses on the architecture of the Web. We assume the reader is familiar with the rationale for some of the general design principles: minimal constraints (fewer rules makes the system more flexible), modularity, minimum redundancy, extensibility, simplicity, and robustness.
Other groups inside and outside W3C are writing down principles related to specialized aspects of Web architecture, including accessibility, internationalization, device independence, and Web Services. The section on Architectural Specifications includes some references.
The TAG intends for this document to inform discussions about issues of Web Architecture. Where current practice conflicts with this document, the TAG expects to engage in constructive discussion with other parties. Some parts of this document may fill in gaps in published specifications or may call attention to known weaknesses in those specifications.
This document promotes reuse of existing standards when suitable, and gives some guidance on how to innovate in a manner consistent with the Web architecture.
Uniform Resource Identifiers (URI), defined by "Uniform Resource Identifiers (URI): Generic Syntax" [URI], are central to Web Architecture. Identifier here is used here in the sense of name. Parties who wish to communicate about something will establish a shared vocabulary, i.e. a shared set of bindings between identifiers and things. This shared vocabulary has a tangible value: it reduces the cost of communication. The ability to use common identifiers across communities is what motivates global naming in Web Architecture.
URIs identify resources. A resource can be be anything. Certain resources are information resources, which convey information. These are termed information resources. Much of this document discusses information resources, often using the term resource.
An information resource is on the Web when it can be accessed in practice.
When a representation of one information resource refers to another information resource with a URI, a link is formed between the two resources. The networked information system is built of linked resources, and the large-scale effect is a shared information space. The value of the Web grows exponentially as a function of the number of linked resources (the "network effect").
Use URIs: All important resources SHOULD be identified by a URI.3
Although there's no precise definition of an "important resource," a resource should have a URI if a third party might reasonably want to link to it, make or refute assertions about it, retrieve or cache a representation of it, transclude all or part of it into another resource, or annotate it.
There are many benefits to making resources identifiable by URI. Some are by design (e.g., linking, bookmarking, and caching), others (e.g., global search services) were not predicted.4
Communication between parties is facilitated by the ability to establish when they are talking about the same thing. The most straightforward way to establish that two parties are refering to the same resource is to compare the spelling (i.e., as strings) of the identifiers the parties are using. Section 6 of [URI] discusses this type of analysis. In that specification, determination of equivalence or difference of URIs is based on string comparison, perhaps augmented by reference to additional rules provided by URI scheme definitions (e.g., for HTTP URIs, the authority component is case-insensitive). Depending on the application, an agent may invest more processing effort to reduce the likelihood of a false negative (i.e., two URIs identify the same resource, but that was not detected).
There may be other ways to establish that two parties are refering to the same resource that are not based on string comparison; see the section on future directions for determining that two URIs identify the same resource.
Agents that reach conclusions about identity beyond what they are licensed
to do (e.g., by specification, or community convention, or site-specific
convention) take responsibility for any problems that result. For instance,
agents should not assume that http://weather.example.com/Oaxaca
and http://weather.example.com/oaxaca
identify the same
resource, since none of the specifications involved states that the path part
of an HTTP URI is case-insensitive. Web servers may vary in how they are
configured to handle case-sensitivity. Agents that assume these URIs identify
the same resource take responsibility for any resulting problems.
Although it is possible to determine that two URIs are equivalent, it is generally not possible by mere inspection of two URIs to be sure that they identify different resources. Web architecture does not constrain resources to be uniquely named.
Good practice
Spelling URIs: If an agent has been provided with a URI to refer to a resource, the agent SHOULD use the spelling of the URI as it was originally provided.
To help parties know when they are referring to the same resource, it
follows that URI producers should be conservative about the number of
different URIs they produce for the same resource. For instance, the parties
responsible for weather.example.com have no reason to use both
to refer to the same resource;
agents will not detect the equivalence relationship. In this case, one URI
should be chosen and used consistently. See section 6.3 of [URI] for further advice on how to reduce the risk of false
URI consumers cannot, in general, determine the meaning of a resource by
inspection of a URI that identifies it. In our travel scenario, the example URI
) suggests that the identified
resource has something to do with the weather in Oaxaca. Although it is
tempetd to infer this, it is not licesed. Although short, meaningful URIs
benefit people, URI consumers must not rely on the URI string to communicate
the meaning of a resource. A site reporting the weather in Oaxaca could just
as easily be identified by the URI http://vjc.example.com/315
And the URI http://weather.example.com/vancouver
might identify
the resource "my photo album." See the section on retrieving a representation for
information about how agents convey information about a resource.
Editor's note: When finding available on URI opacity, link from here.
In the URI http://weather.example.com/
, the "http" that
appears before the colon (":") is a URI scheme name. There are other schemes,
such as "mailto" and "ftp". It is common to classify URIs by scheme; a URI
with scheme "http" is called an "HTTP URI."
Each URI begins with a URI scheme name. The scheme name corresponds to a specification for assigning identifiers within that scheme. As such, the URI syntax is a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme. Furthermore, the URI scheme specification specifies how an agent can dereference the URI.
Several URI schemes incorporate identification mechanisms that pre-date the Web into this syntax:
Other URI schemes have been introduced since the advent of the Web, including those introduced as a consequence of new protocols. Examples of URIs for these schemes include:
The Internet Assigned Numbers Authority (IANA) maintains a registry [IANASchemes] of mapping between URI scheme names and their specifications. For instance, the IANA registry indicates that the "http" scheme is defined by [RFC2616]. The process for registration of new URI schemes is defined by RFC2717.
Since many aspects of URI processing are scheme-dependent, and since a huge amount of deployed software already processes URIs of well-known schemes, the cost of introduction of new URI schemes is high.
Good practice
New URI schemes: Authors of specifications SHOULD avoid introducing new URI schemes when existing schemes can be used to meet the goals of the specifications.
Consider our travel scenario: should
the authority providing information about the weather in Oaxaca register a
new URI scheme "weather" for the identification of resources related to the
weather? They might then publish URIs such as
. While the Web Architecture
allows the definition of new schemes, there is a cost to registration and
especially deployment of new schemes. When an agent dereferences such a URI,
if what really happens is that HTTP GET is invoked to retrieve an HTML
representation of the resource, then an HTTP URI would have sufficed. If a
URI scheme exists that meets the needs of an application, designers should
use it rather than invent one. Furthermore, designers should expect that it
will prove useful to be able to share a URI across applications, even if that
utility is not initially evident.
If the motivation behind registering a new scheme is to allow an agent to launch a particular application when retrieving a representation, such dispatching can be accomplished at lower expense by registering a new media type instead.
The use of unregistered URI schemes is discouraged for a number of reasons:
In the URI http://weather.example.com/
, the string
(between "//" and the next "/") called the
authority component. Many URI schemes include a hierarchical element for a
naming authority
such that governance of the name space defined by the remainder of the URI is
delegated to that authority (which may, in turn, delegate it further). The
generic syntax provides a common means for distinguishing an authority based
on a registered domain name or server address. See section 3.2 of [URI] for more information about the authority
portion of a URI.
How authority is delegated depends on the URI scheme. The deployment and use of different URI schemes may require varying degrees of central coordination and administration. For example, MAILTO, FTP, and HTTP URIs depend on the use of the DNS and IANA infrastructure; see "ICP-1: Internet Domain Name System Structure and Delegation" [IANAICP1] for more information about how the IANA manages delegation of domain names.
Successful communication between two parties about a piece of information relies on shared understanding of the meaning of the information. Thousands of independent parties can identify and communicate about a Web resource. To give these parties the confidence that they are all talking about the same thing when they refer to "the resource identified by the following URI ..." the design choice for the Web is, in general, that the owner of a resource assigns the authoritative interpretation of representations of the resource. See the draft TAG finding "Client handling of MIME headers" for related discussion.
In our travel scenario, the agent
responsible for weather.example.com
has license to create
representations of this resource and assign their authoritative
In our travel scenario the server
returns an XHTML representation when Dan dereferences the URI
. Then, by navigating within
the XHTML content, Dan finds that the URI
refers to information
about tomorrow's weather in Oaxaca. This URI includes the fragment identifier
"tom" (the string after the "#").
The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource.
When a resource has a URI and has a representation; and in the language of that representation (using a syntax and semantics defined by the MIME type specification) a given string identifies a second resource, then the concatenation of the URI, a hash mark and the string forms a URI for that second resource.
Although the generic URI syntax allows any URI to end with a fragment identifier, some URI schemes do not specify the use of fragment identifiers. For instance, fragment identifier usage is not specified for MAILTO URIs.
For URI schemes that do specify the use of fragment identifiers, the syntax and semantics of those identifiers is defined by the set of representations that might result from a retrieval action on the primary resource. The presence of a fragment identifier component in a URI does not imply that a retrieval action will take place.
Interpretation of the fragment identifier during a retrieval action is performed solely by the user agent; the fragment identifier is not passed to other systems during the process of retrieval. This means that some intermediaries in the Web architecture (e.g., proxies) have no effect on fragment identifiers and that redirection (in HTTP [RFC2616], for example) does not account for them.
Suppose that the managers of weather.example.com
provide a
visual map of the meteorological conditions in Oaxaca as part of the
representation served for http://weather.example.com/oaxaca
They might encode the same visual map in a number of image formats to meet
different needs (e.g., they might serve PNG, SVG, and JPEG/JFIF). Dan's user
agent and the server engage in HTTP content negotiation, so that Dan receives
the best image format his user agent can handle or the format he usually
prefers. The URI http://weather.example.com/oaxaca/map#zicatela
refers to a portion of the weather map that shows the Zicatela Beach, where
Dan intends to go surfing. Clients can do something useful with the fragment
identifier and the SVG representation, since SVG defines fragment identifier
semantics. Clients should not be expected to do something useful with the
fragment identifier for the PNG or JPEG/JFIF representations since those
specifications do not define fragment identifier semantics.
Good practice
Content negotiation with fragments: Authors SHOULD NOT use HTTP content negotiation for different media types that have incompatible fragment identifier semantics.
Given a URI, a system may attempt to perform a variety of operations on the resource, as might be characterized by such words as "access", "update", "replace", or "find attributes". Available operations depend on the formats and protocols that make use of URIs. The URI specification (in [URI], section 1.2.2) defines the following terms related to interactions through a URI.
During access of a resource, an agent applies a succession of relevant specifications, beginning with the specification of the context in which the URI is found (e.g., a format or protocol specification, or an application). Any one of these specifications may define more than one access mechanism (e.g., the HTTP protocol defines a number of access methods, including GET, HEAD, and POST). Note that the information governing the choice of access mechanism may be found in the context, not the URI itself (e.g., the choice of HTTP GET v. HTTP HEAD). The draft TAG finding "URIs, Addressability, and the use of HTTP GET and POST." discusses issues surrounding multiple access mechanisms and the relation to URI addressability.
Some URI schemes (e.g., the URN scheme [RFC 2141]) do not define dereference mechanisms.
TAG issue metadataInURI-31: Should metadata (e.g., versioning information) be encoded in URIs?
TAG issue siteDate-26: Web site metadata improving on robots.txt, w3c/p3p and favicon etc.
One of the most important actions involving a resource is to retrieve a representation of it (for example, by using HTTP GET). As stated above, the authority responsible for a URI determines what the URI identifies and which representations are used for interaction with the resource. The representations communicate some or all of the state of the resource.
Good practice
Resource descriptions: Owners of important resources SHOULD make available representations that describe those resources.
As an example of representation retrieval, suppose that the URI
is used within an
element of an SVG document. The sequence of specifications
applied is:
link involves retrieving
a representation of a resource, identified by the XLink href
attribute: "By activating these links (by clicking with the mouse,
through keyboard input, and voice commands), users may visit these
is defined in section 5.4 of the
XLink 1.0 [XLink10] specification
states that "The value of the href attribute must be a URI reference as
defined in [IETF RFC 2396], or must result in a URI reference after the
escaping procedure described below is applied."Note that, in general, one cannot determine the media type(s) of
representation(s) of a resource by inspecting a URI for that resource. For
example, do not assume that all representations of
are HTML. The HTTP protocol does
not constrain the media type based on the path component of the URI; the
server is free to return a PNG image representation.
Editor's note: It is an open question whether the TAG will define and use the phrase "on the Web" in this document. Definitions that have been suggested include "is identified by a URI" and "is identified by a URI and at least one representation is available for retrieval."
Dan's retrieval of weather information qualifies as a "safe" interaction; a safe interaction is one where the user agent does not commit to anything beyond the interaction and is not responsible for any consequences other than the interaction itself (e.g., a read-only query or lookup). Other Web interactions resemble orders more than queries. These unsafe interactions may cause a change to the state of a resource; the user may be held responsible for the consequences of these interactions. Unsafe interactions include subscription services, posting to a list, or modifying a database.
Safe interactions are important because these are interactions where users can browse with confidence and where software programs (e.g., search engines and browsers that pre-cache data for the user) can follow links safely. Users (or software agents acting on their behalf) do not commit themselves to anything by querying a resource or following a link.
Safe retrieval: Agents do not incur obligations by retrieving a representation.
For instance, suppose in our travel
scenario that the managers of weather.example.com
offer a
monthly newsletter available by subscription. It is incorrect and
harmful to publish a page
that states "... terms
and conditions..." with a link to
because search services may
link directly to http://example.com/oxaca/newsLetter
and readers
that follow such links may not have seen, let alone agreed to, the terms and
For more information about safe and unsafe operations using HTTP GET and POST, and handling security concerns around the use of HTTP GET, see the draft TAG finding "URIs, Addressability, and the use of HTTP GET and POST."
The value of a URI increases with the predictability of interactions using that URI.
Good practice
URI Persistence: Parties responsible for a URI SHOULD service that URI predictably and consistently.
Service breakdowns include:
There are strong social expectations that once a URI identifies a particular resource, it should continue indefinitely to refer to that resource; this is called URI persistence. URI persistence is always a matter of policy and commitment on the part of authorities servicing URIs rather than a constraint imposed by technological means.
URI Ambiguity is the use of the same URI to refer to more than one distinct thing, and should be avoided.
In a simple example, one part of an enterprise has data about web pages, included who created them and when. Another part of the company has data about companies, including who created them and when. The second dataset uses the URIs of the organization's home page as though it was the URI of the organization itself. When data is merged, the reuse of the URI causes information about companies to be merged with that of the home pages, resulting in contradictory nonsense.
Ambiguity, should not be confused with indirect identification, which is normal. One indirectly identifies things though related things, such as people by their mailboxes, and organizations by their web pages. For example, when you are asked to register the participants at a meeting by giving email addreses, both sides know that they are using the identifier for a mailbox to indirectly identify the person. The URI still in the architecture is the URI of the mailbox, not the person.
The RDF language allows things of any kind to be described and allocated a URI, such that dereferencing the URI then yields that description. This avoids ambiguity between the document and any of the things it describes.
HTTP [RFC2616] has been designed to help service URIs. For example, HTTP redirection (via some of the 3xx response codes) permits servers to tell an agent that further action needs to be taken by the agent in order to fulfill the request (e.g., the resource has been assigned a new URI). In addition, content negotiation also promotes consistency, as a site manager would not be required to define new URIs for each new format that is supported, as would be the case with protocols that don't support content negotiation, such as FTP.
For more discussion about URI persistence, refer to [Cool].5
As we have seen, identification of a resource is distinct from interacting with that resource. It is reasonable to control access to the resource (e.g., for security reasons), but it is unreasonable to prohibit others from merely identifying the resource.
As an analogy: A building might have a policy that the public may only enter via the main front door, and only during business hours. People employed in the building and in making deliveries to it might use other doors as appropriate. Such a policy would be enforced by a combination of security personnel and mechanical devices such as locks and pass-cards. One would not enforce this policy by hiding some of the building entrances, nor by requesting legislation requiring the use of the front door and forbidding anyone to reveal the fact that there are other doors to the building.
In the travel scenario, imagine that
Dan and Norm both subscribe to the weather.example.com
newsletter. Dan wishes to point out an article of particular interest to
Norm, using a URI. The managers of weather.example.com
can offer
Dan and Norm the benefits of URIs (e.g., bookmarking and linking) and still
control access to the newsletter by authorized parties. The Web provides
several mechanisms to control access to resources, none of which relies on
hiding or suppressing URIs for those resources. For more information on
identification and access control, please refer to the TAG finding "'Deep
Linking' in the World Wide Web."
The integration of internationalized identifiers (i.e., composed of characters beyond those allowed by [URI]) into the Web Architecture is an important and open issue. See TAG issue IRIEverywhere-27 for discussion about work going on in this area.
Emerging Semantic Web technologies, including "DAML+OIL" [DAMLOIL] and "Web Ontology Language (OWL)" [OWL10], define RDF properties such as
and FunctionalProperty
to state -- or
at least claim -- formally that two URIs identify the same resource.
There has been some discussion but no agreement that new access protocols should provide a means to convert fragment identifiers according to media type.
Fragment identifier semantics may differ among formats. See related TAG issues httpRange-14 and RDFinXHTML-35 and abstractComponentRefs-37.
The Dynamic Delegation Discovery System (DDDS) ([RFC3401] and related RFCs) is used to implement lazy binding of strings to data, in order to support dynamically configured delegation systems. This system is designed to allow resolution of any type of URI, in particular URNs.
One area of work involves the creation of globally unique identifiers in a file-sharing system without centralized or hierarchical administration.
A representation is data that represents or describes the state of a resource. It consists of:
Web agents use representations to modify as well as retrieve resource state.
When agents transfer representations via messages (see the section on interactions for information about message protocols), the message often includes additional metadata that is not part of the representation (e.g., the HTTP Server field or the request method, URI, etc.). A message may even include "meta-metadata" (for message-integrity checks). The representation consists of those bits that would not change regardless of the transfer protocol used to exchange them.
In our previous travel scenario the representation Dan receives (and whether he receives one at all) depends on a number of factors, including:
respond to requests at all;weather.example.com
make available one or more representations for the resource identified by
provided more than one representation (in different formats such as HTML,
PNG, or RDF, in different languages such as English and Spanish, etc.),
the resulting representation may depend on negotiation between the user
agent and server that occurs as part of the HTTP transaction.We discuss these issues in more detail below.
As discussed above, the owner of a resource assign URIs for that resource, create representations of the resource, and assign their authoritative interpretation. This interpretation is described in part by metadata that is part of the representation, notably the Internet media type. At times there may be inconsistencies between metadata and what is specified in a format. Examples of inconsistencies between headers and format data that have been observed in practice include:
User agents should detect such inconsistencies but should not resolve them without involving the user (e.g., by securing permission or at least providing notification). User agents must not silently ignore authoritative server metadata.
See the draft TAG finding "Client handling of MIME headers" for more in-depth discussion and examples.
The Web can be used to interchange resource representations in any format. This flexibility is important, since there is continuing progress in the development of new data formats for new applications and the refinement of existing ones.
For a format to be usefully interoperable between two parties, the parties must have a shared understanding of its syntax and semantics. This is not to imply that a sender of data can count on constraining its treatment by a receiver; simply that making good use of electronic data usually requires knowledge of its designers' intentions.
For a format to be widely interoperable across the Web:
Although the Web architecture allows for the deployment of new data formats, the creation and deployment of new formats (and software able to handle them) can be very expensive. Thus, before inventing a new data format, designers should carefully consider re-using one that is already available. For example, if a format is required to contain human-readable text with embedded hyperlinks, it is almost certainly better to use HTML for this purpose than to invent a new format.
As noted above, the utility of data formats starts with the availability of a normative specification. Some of the desirable characteristics of a format include:
The section on architectural specifications includes references to additional format specification guidelines.
Other design issues:
This section discusses important characteristics of data formats which can together be used to describe and understand them.
A textual data format is one in which the data is specified as a linear sequence of characters. HTML, Internet e-mail, and all XML-based languages are textual. In modern textual data formats, the characters are usually taken from the Unicode repertoire.
Binary data formats are those in which portions of the data are encoded for direct use by computer processors, for example thirty-two bit little-endian two's-complement and sixty-four bit IEEE double-precision floating-point. The portions of data so represented include numeric values, pointers, and compressed data of all sorts.
In principle, all data can be represented using textual formats.
The trade-offs between binary and textual data formats are complex and application-dependent. Binary formats can be substantially more compact, particularly for complex pointer-rich data structures. Also, they can be consumed more rapidly by software in those cases where they can be loaded into memory and used with little or no conversion.
Textual formats are often more portable and interoperable, since there are fewer choices for representation of the basic units (characters), and those choices are well-understood and widely implemented.
Textual formats also have the considerable advantage that they can be directly read and understood by human beings. This can simplify the tasks of creating and maintaining processing software, and allow the direct intervention of humans in the processing chain without recourse to tools any more complex than the ubiquitous text editor. Finally, it simplifies the necessary human task of learning about new data formats (the "View Source" effect).
It is important to emphasize that intuition as to such matters as data size and processing speed are not a reliable guide in data format design; quantitative studies are essential to a correct understanding of the trade-offs.
TAG issue binaryXML-30: Effect of Mobile on architecture - size, complexity, memory constraints. Binary infosets, storage efficiency.
Final-form data formats are not designed to allow modification or uses other than that intended by their designers. An example would be PDF, which is designed to support the presentation of page images on either screen or paper, and is not readily used in any other way. XSL Formatting Objects (XSL-FO) share this characteristic.
XHTML, on the other hand, can be and is put to a variety of uses including direct display (with highly flexible display semantics), processing by network-sensitive Web spiders to support search and retrieval operations, and reprocessing into a variety of derivative forms.
In general XML-based data formats are more re-usable and repurposable than the alternatives, although the example of XSL-FO shows that this is not an absolute.
There are many cases where final-form is an application requirement; representations which embody legally-binding transactions are an obvious example. In such cases, the use of digital signatures may be appropriate to achieve immutability, whether the format is naturally final-form or some XML vocabulary.
On the other hand, where such requirements are not in play, representations that are reusable and repurposable are in general higher in value, particularly in the case where the information's utility may be long-lived.
Some data formats are explicitly designed to be used in combination with others, while some are designed for standalone use. An example of a standalone data format is PDF; it is not typically embedded in representations encoded in other formats.
At the other extreme is SOAP, which is designed explicitly to contain a "payload" in some non-SOAP vocabulary. Another example is SVG, which is designed to be included in compound documents, and which may in turn contain information encoded in other XML vocabularies.
This characteristic is related to, but distinct from, the final-form/reusable distinction discussed above. For example, one can certainly imagine cases where it is useful for a representation to include data in multiple different formats, but be considered immutable and display-only.
TAG issue xmlProfiles-29: When, whither and how to profile W3C specifications in the XML Family?
TAG issue mixedUIXMLNamespace-33: Composability for user interface-oriented XML namespaces
TAG issue xmlFunctions-34: XML Transformation and composability (e.g., XSLT, XInclude, Encryption)
TAG issue RDFinXHTML-35: Syntax and semantics for embedding RDF in XHTML
XML and XML Namespaces allow format designers to create and combine vocabularies. A format is extensible if instances of the format can include terms from other vocabularies.
Good practice
Extensibility: Format designers should create extensible formats.
Versioning is the term for the evolution of languages and documents. Versioning is achieved through extensibility mechanisms and language redefinition. When a format definition changes (e.g., by addition or removal of element or attribute definitions), this creates a new version of the format. When an instance of a format includes other vocabulary elements, this creates an extension of the instance; the original format definition has not changed. An example is a SOAP message with a header block, this is called a SOAP extension, not a new version of the SOAP format.
The following terms define important relationships among different versions of a format:
Good practice
Compatibility: Format designers SHOULD define extensibility models that allow forwards compatible and backwards compatible changes.
Naturally, even if M and N are compatible but different versions of a format, agents will process instances of them differently. For instance, if format version M is forwards compatible with format version N, M processors that encounter N instances might handle unknown elements by ignoring them entirely, or by ignoring element tags but continuing to process element content. Different format specifications may require different compatibility behavior.
Good practice
Compatibility behavior: Format designers SHOULD define expected behavior when agents designed to process one version of a format encounter a compatible version of the format.
In some cases, format designers require that new features be supported
(i.e., not ignored). In this case, the new version of the format (N) may be
backwards compatible with the earlier version (M), but M is not forwards
compatible with N. The SOAP 1.2 Recommendation [SOAP12], for example, defines the
attribute in section
For more information on format extensibility, refer to "Web Architecture: Extensible Languages" [EXTLANG].
In many cases, the information contained in a separation is logically separable from the choice of ways in which it may be presented to a human, and the modes of interaction it may support.
While such separation is, where possible, often advantageous, it is clearly not always possible and in some cases not desirable either.
Replacement text from C. Lilley expected.
One of the greatest strengths of HTML as a format is that it allows authors to embed cross references (hyperlinks). The simplicity of <a href="#foo"> as a link to "foo" and <a name="foo"> as the anchor "foo" are partly (perhaps largely) responsible for the birth of the hypertext Web as we know it today.
Simple, single-ended, single-direction, inline links are not the most powerful linking paradigm imaginable. But they are very easy to understand. And they can be authored by individuals (or other agents) that have no control or write access to the other end point.
More sophisticated linking mechanisms have been invented for the Web. XPointer allows links to address content that does not have an explicit, named anchor. XLink allows links to have multiple ends and to be expressed either inline or in "link bases" stored external to any or all of the resources identified by the links it contains.
All of the current common linking mechanisms identify resources by URI and optionally identify portions (or views) of a resource with the fragment identifier.
Good practice
Link mechanisms: Format specification designers SHOULD provide mechanisms for identifying links to other resources and to portions of representations (via fragment identifiers).
For formats based on XML, format designers should examine XLink and the XPointer framework for inspiration. To define fragment identifier syntax, use at least the XPointer Framework and XPointer element() Schemes.
If a future revision of RFC 3023 identifies the XPointer Framework, element(), and perhaps other ancillary schemes as the fragment identifier syntax for XML documents, authors will be able to rely on at least those schemes for all XML documents.
TAG issue: What is the scope of using XLink? xlinkScope-23.
Many resource representations are encoded in formats which are XML vocabularies. This section discusses issues that are specific to such data formats.
Anyone seeking guidance in this area is urged to consult the "Guidelines For The Use of XML in IETF Protocols" [IETFXML] for the use of XML in Internet Protocols. This document contains a very thorough discussion of the considerations that govern whether or not XML ought to be used, as well as specific guidelines on how it ought to be used. While it is directed at Internet applications with specific reference to protocols, the discussion is generally applicable to Web scenarios as well.
The discussion here should be seen as ancillary to the content of the IETF BCP. Refer also to "XML Accessibility Guidelines" [XAG] for help designing XML formats that lower barriers to Web accessibility for people with disabilities.
XML defines textual data formats that are naturally suited to describing data objects which are hierarchical and processed in an in-order sequence. It is widely but not universally applicable for format specifications. For example, an audio or video format is unlikely to be well suited to representation in XML. Design constraints that would suggest the use of XML include:
Editor's note: Which XML Specifications make up the XML Family?
The Web is significantly a networked information system. Authors and applications can use URIs uniformly to identify different resources. After representations of these resources have been retrieved, they may be processed in a variety of ways. Some applications (and some users) will undoubtedly build new resources by combining several representations together. This is particularly easy, and potentially useful, when XML representations are available for all the resources.
However, combining representations in this way moves them out of their original context and places them in a new context. This change of context introduces the possibility of information loss. Any information that depended on the local context will no longer be available.
What is needed is a mechanism for establishing a global context for the elements and attributes in the XML resources. This problem bears a strong resemblance to the distinction between relative and absolute URIs. While the many hundreds of relative URI references to "index.html" on a typical web server may be entirely unambiguous in their respective contexts, they have no unambiguous global meaning. But each such relative URI has an unambiguous absolute URI that can be established in its local context and used when a document is moved. This solves the problem for URI references.
For elements and attributes, their names can be seen as analogous to relative URI. Within their original context, they have meanings that are clear and entirely unambiguous. Namespaces in XML provides a mechanism for establishing a globally unique name that can be understood in any context.
The "absolute" form of an XML element or attribute name is the combination of its namespace URI and its local name. This is represented lexically in documents by associating namespace names with (optional) prefixes and combining prefixes and local names with a colon as described in "Namespaces in XML" [XMLNS].
Designers that use namespaces are thus providing a global context for documents authored with their schema. Establishing this global context allows their documents (and portions of their documents) to be reused and combined in novel ways not yet imagined. Failure to provide a namespace makes such reuse more difficult, perhaps impractical in some cases.
The most significant technical drawback to using namespaces is that they do not interact well with DTDs. DTDs perform validation based on the lexical form of the name, making prefixes semantically significant in ways that are not desirable. As other schema language technologies become widely deployed, this drawback will diminish in significance.
Namespace designers SHOULD make available human-readable material to meet the needs of those who will use the namespace vocabulary. The simplest way to achieve this is for the namespace name to be an HTTP URI which may be dereferenced to access this material. The resource identified by such a URI is called a "namespace document."
There are many reasons why a person or agent might want more information about the namespace. A person might want to:
A namespace document should also support the automatic retrieval of other Web resources that support the processing markup from this vocabulary. Useful information to processors includes:
It follows that there is, in general, no single type of resource that can be returned in response to a request for the namespace name that will always be the most appropriate; see the section on future work regarding namespace document formats for more information.
Issue: namespaceDocument-8: What should a "namespace document" look like?
Issue: abstractComponentRefs-37: Definition of abstract components with namespace names and frag ids
Editor's note: Where should we put a section on mixing namespaces; is the section on processing model more appropriate? See issue mixedUIXMLNamespace-33.
Suppose that the URI http://example.com/oaxaca
defines a
resource with representations encoded in XML. What, then, is the
interpretation of the URI http://example.org/oaxaca#weather
The URI specification [URI] makes it clear that the interpretation depends on the context of the media type of the representation. It follows from this that designers of XML-based data formats SHOULD include the semantics of fragment identifiers in their designs. The XPointer Framework [XPTRFR] provides a syntax designed for in such fragment identifiers, and it SHOULD be used for this purpose.
When a representation is provided whose media type is
, there are no semantics defined for fragment
identifiers, and thus they SHOULD NOT be provided for such representations.
This is also the case if the representation is known to be XML because the
media type has a suffix of +xml
as described in "XML Media
Types" [RFC3023], but there is no
normative specification of fragment semantics.
It is common practice to assume that when an element has an attribute that
is declared in a DTD to be of type ID, then the fragment identifier
identifies the element which has an attribute of that type
whose value is "abc"
. However, there is no normative support for
this assumption and it is problematic in practice, since the only defined way
to establish that an attribute is of type ID is via a DTD, which may not
exist or may not be available.
TAG issue fragmentInXML-28: Do fragment identifiers refer to a syntactic element (at least for XML content), or can they refer to abstractions? See TAG issue.
TAG issue xmlIDSemantics-32: How should the problem of identifying ID semantics in XML languages be addressed in the absence of a DTD? See draft TAG finding "How should the problem of identifying ID semantics in XML languages be addressed in the absence of a DTD?".
RFC 3023 defines the media types application/xml
, and describes a convention whereby XML-based data
formats use media types with a +xml
suffix, for example
In general, media types beginning with text/
SHOULD NOT be
used for XML representations. They create two problems: First, intermediate
agents in the Web are allowed to "transcode", i.e., convert one character
encoding to another. Since XML documents are designed to allow them to be
self-describing, and since this is a good and widely-followed practice, any
such transcoding will make the self-description false.
Secondly, representations whose media types begin with text/
are required, unless the charset
parameter is specified, to be
considered to be encoded in US-ASCII. In the case of XML, since it is
self-describing, it is good practice to omit the charset
parameter, and since XML is very often not encoded in US-ASCII, the use of
" media types effectively precludes this good practice.
This section will describe the architectural principles and constraints regarding interactions between components, including such topics as network protocols and interaction styles, along with interactions between the Web as a system and the people that make use of it. This will include the role of architectural styles, such as REST and SOAP, and the impact of meta-architectures, such as Web Services and the Semantic Web.
Good practice
Glossary not yet completed.
Editor's note: The TAG is still experimenting with the categorization of points in this document. This list is likely to change. It has also been suggested that the categories clearly indicate their primary audience.
The important points of this document are categorized as follows:
had been chosen instead, the large-scale result
would, most likely, have been the same. Other design choices are more
fundamental; these are the focus of this document.Editor's note: The usage of a normative reference in this document needs clarification.
The authors of this document are the participants of W3C's Technical Architecture Group: Tim Berners-Lee (Chair, W3C), Tim Bray (Antarctica Systems), Dan Connolly (W3C), Paul Cotton (Microsoft), Roy Fielding (Day Software), Chris Lilley (W3C), David Orchard (BEA Systems), Norman Walsh (Sun), and Stuart Williams (Hewlett-Packard).
The TAG thanks people for their thoughtful contributions on the TAG's public mailing list, www-tag (archive).


text:
Cops 'ticket' twin toddlers in Washington Heights
NEW YORK (FOX5NY) - Twin toddlers out for an apparent joy ride Sunday in the Washington Heights neighborhood of Manhattan were stopped by two NYPD officers.
The brothers were behind the wheel of a large toy car on the sidewalk when the officers got out of their patrol car and approached the boys with a summons in hand.
"Stopping traffic over here on St. Nicholas Avenue," a male voice is heard saying off-camera.
According to the NYPD, the boys were "issued a warning."
"As everyone in NYC knows driving on the sidewalk is strictly prohibited, but these two little guys got off with a warning (plus a high five and two new friends)!" reads the caption on video posted by the NYPD to Facebook.

subset: commoncrawl


text: I have been making jewelry for many years, (About 9 now) and many times have shopped at Fire Mountain Gems, they have quality merchandise, fast and friendly service. And they offer $5 Best Way Select Economy Shipping. They don't profit from shipping……. Now they are offering the Biggest Sale Ever! Save up to 82% off over 25,000 items, including beads, jewelry […] Biggest Sale Ever! Fire Mountain GemsDecember 11, 2014 in Affiliate / jewlery / Sales tagged Alberta Ferretti / Bead / Best Way / Black Friday (shopping) / Business Wire / Candlestick / Companies law / Crystal / Swarovski / Victoria's Secret by Karren Haller


text:
Bitlish is a London-based crypto trading company that started in April 2015. The platform offers a secure and convenient exchange. Its process is also simple and very much easy to follow. Another unique thing about Bitlish is the fact that there's no maker fee. It means that there's no charge when making offers on the platform.
Below, you will find the steps you can follow to start trading on Bitlish.
Click here to open the exchange site.
Once the site is up, tick on the 'Create account' or 'Buy Bitcoins within Five Minutes' button.
Type in your email address/phone number and password in their respective fields. Put a check mark on the 'I'm not a robot' box and hit Create account.
If you enter your email address, you will have to open your email to confirm.
In the email, click on the 'Confirm your contact' button or copy and paste the URL provided into your browser.
Click 'Continue' to proceed.
Our next step is to verify your phone number. To start, hit on the 'Login' button.
Input the email address and password that you used for registration. Check the 'I'm not a robot' box and hit Login.
Select your Country Code and type in your Phone Number. Hit Save to continue.
Retrieve the confirmation code that you receive in your phone number. Enter it on the field provided and click Confirm.
You will get this message once this step complete.
For you to experience Bitlish with its full functionalities, which includes depositing and withdrawing of funds, your account must pass verification. Trade fee will also be lower compared to those unverified accounts.
To begin, click on the 'Profile' icon located in the upper part of the screen.
On your Profile page, click on the 'Verification' tab.
On the next slide, read all the required information and make sure to follow the instructions to avoid delays.
Here, you're required to enter your personal information.
After providing all the needed information, hit on the 'Apply for verification' button.
Typically, verification on Bitlish only takes a couple of minutes to an hour. It may take more than that but won't pass the 24-hour mark. You will also receive an email notification regarding this request.
What is 2FA?
Two-factor authentication, also known as 2FA, is an extra layer of security or added protection which we refer as multi-factor authentication. Not only the username and password are required but also a piece of information that only a user possesses. This process is to confirm a user's claimed identity.
The 2FA process helps lessen the number of identity theft cases and as well as phishing via email. It would be harder for potential intruders to gain access and steal someone's identity and personal data without that piece of information that only the account owner knows.
In the case of exchanges what the user has are his/her login details such as the username and password. The form of 2FA that a user possesses for this instance is a token or code. The code can be received either through SMS on a user's mobile phone or via applications like Google Authenticator or Authy.
In this step, we will activate 2FA on your Bitlish account through the Authy app. To do this, go to your profile and click on the 'Edit profile' button.
Click this if you want to know more about Authy. You can also download the app through the link provided.
Under 'Two-factor authentication method' do select Authy. Additionally, choose 'Enabled' from the drop-down menus of Use two-factor authentication for sign in and Use two-factor authentication for Withdraw. Then click Save.
Copy the confirmation code that was delivered to your phone number, enter it on the box provided, and click Confirm.
Get the confirmation code from the Authy app that you downloaded to your smartphone and type it in the box below. Hit Confirm to proceed.
Now, it is safe to put money into your account. Here, you will deposit with the use of fiat currencies (EUR, USD, RUB).
On the upper right of the page click on the icon beside the flag.
Locate the Balance section and click on 'Deposit' under the fiat currency you wish to fund.
Enter the deposit amount, choose your preferred Pay System and then hit Proceed. Read the instructions on the next screen and follow them to complete the process.
Note: Deposits via VISA/MasterCard are credited immediately. Whereas, it may take up to 5 business days for Bank transfers. Also, bank transfers are allowed only for some countries.
Since your Bitlish account already has money in it, you can now buy your first Monero (XMR)!
Click on the icon next to the flag and select the Monero (XMR) you wish you buy.
Select the account you intend to get the funds from (Arrow A) and the amount you're willing to spend (Arrow B). The amount of Monero (XMR) that you'll get will appear which would depend on the amount you enter. You can also do it in vice-versa by changing the selection to Monero (XMR) (Arrow B). When you do this, the amount you're going to spend will show up after entering the amount of Monero (XMR) that you want to get. Click the 'Buy' button to continue.
If you are a professional or someone who is no longer new to trading, you may opt to select the 'For Professionals' button after hitting the icon beside the flag.
After getting into the page, select the Monero (XMR) that you want to purchase with the corresponding fiat currency where you deposited your funds. This combination is your Trading Pair.
Look for the 'Buy/Sell' section and under Buy, enter the amount of Monero (XMR) that you plan to attain or the amount that you are willing to spend. Review all the information and if everything is correct hit on Buy.
Under the 'Buy/Sell' section, is where you can view the order you just made (Open orders).
Trading and investing in digital assets is highly speculative and comes with many risks. The analysis/stats on CoinCheckup.com and it's subsites are for informational purposes and should not be considered investment advice and or the truth. Statements and financial information on CoinCheckup.com and it's subsites should not be construed as an endorsement or recommendation to buy, sell or hold.
Please do your own research on all of your investments carefully. Scores are based on averages of third party websites. Past performance is no indicative of future results. Read the full disclaimer here.


text:
This is a great value driver, designed particularly for beginners and improving golfers.
15° #3 head and 18° #5 head - gives you a huge sweetspot and more forgiveness, and just inspires confidence when you address the ball.
Steel shaft - cut slightly shorter than graphite - gives you greater control. Regular flex. Shaft length: 41"
Matching headcover included to keep your driver in great shape in transit
Fitted with a Ram All Weather grip.
item specifications
Brand | Ram |
Player | Male |
Dexterity | Right Handed |
Flex | Regular |
You can buy with confidence, knowing that your products are backed with a great warranty.
Unless it is otherwise stated in the product description, new items come with a 12 month warranty against faulty craftsmanship or inherent defects.
We have a fully stocked and staffed repair centre here in the Midlands, carrying lots of parts and spares, and in many cases can help you outside of the normal warranty.
Please note the warranty does not cover damage caused by normal wear and tear, accidents, misuse, lack of maintenance, neglect, natural disaster, or other external causes; to damage caused by operating the equipment in a manner outside that described in the instructions. The warranty is considered void if the item has been modified, altered or tampered with by a person not authorised by S247 PLC to provide service (not including standard periodic maintenance).
Have a question about this product?


text:
Managing Partner
Entrust Wealth Management
We are dedicated to providing investment management and strategic wealth planning to that is specific to you and your situation. Simply put, we strive to be our client's trusted advisor. As a financial advisory firm, our primary focus is to provide unbiased opinions that are designed to achieve long term investment results.
We are dedicated to professionally supporting, educating, and providing informed direction to each and every client and we do this with the highest levels of trust, integrity and respect while always collaborating using a team approach.


text:
Spring has arrived!
Spring has sprung, and with the change of season, our thoughts turn to Easter celebrations, spring cleaning and much-needed home improvement projects. Before you embark on seasonal chores or outdoor revelry, take inventory of potential springtime hazards for your furry friends.
*If you suspect your pet may have come in contact with or ingested a potentially poisonous substance, contact your local veterinarian or the ASPCA Animal Poison Control Center immediately at (888) 426-4435.
Easter Treats and Decorations
Keep lilies and candy in check—chocolate goodies are toxic to cats and dogs, and all true lilies can be fatal if ingested by cats. And be mindful, kitties love to nibble on colorful plastic grass, which can lead to an obstructed digestive tract, severe vomiting and dehydration. Moreover, while live bunnies, chicks and other festive animals are adorable, resist the urge to buy them—these cute babies grow up fast and often require specialized care!
Screen Yourself
Many pet parents welcome the breezy days of spring by opening their windows. Unfortunately, they also unknowingly put their pets at risk—especially cats, who are apt to jump or fall through unscreened windows. Be sure to install snug and sturdy screens in all of your windows.
Buckle Up!
While most dogs love to feel the wind on their furry faces, allowing them to ride in the beds of pick-up trucks or stick their heads out of moving-car windows is dangerous. Flying debris and insects can cause inner ear or eye injuries and lung infections, and abrupt stops or turns can cause major injury, or worse! Pets riding in cars should always be secured in a crate or wearing a seatbelt harness designed especially for them.
Spring Cleaning
Spring cleaning is a time-honored tradition in many households, but be sure to keep all cleaners and chemicals out of your pets' way! Almost all cleaning products, even all natural ones, contain chemicals that may be harmful to pets. The key to using them safely is to read and follow label directions for proper use and storage. Please visit our Poisonous Household Products page for more information.
Home Improvement 101
Products such as paints, mineral spirits and solvents can be toxic to your pets and cause severe irritation or chemical burns. Carefully read all labels to see if the product is safe to use around your furry friends. Also, be cautious of physical hazards, including nails, staples, insulation, blades and power tools. It may be wise to confine your dog or cat to a designated pet-friendly room during home improvement projects.
Let Your Garden Grow—With Care
Pet parents, take care—fertilizers, insecticides and herbicides keep our plants and lawns healthy and green, but their ingredients may be dangerous if your pet ingests them. Always store these products in out-of-the-way places and follow label instructions carefully. Many popular springtime plants—including rhododendron and azaleas—are also highly toxic to pets and can prove fatal if eaten. Check out our full list—of toxic and non-toxic plants for your home and garden.
Like us, pets can be allergic to foods, dust, plants and pollens. Allergic reactions in dogs and cats can cause itching, minor sniffling and sneezing, or life-threatening anaphylactic shock to insect bites and stings. If you suspect your pet has a springtime allergy, please visit your veterinarian as soon as possible.
Pesky Little Critters
April showers bring May flowers—and an onslaught of bugs! Make sure your pet is on year-round heartworm preventive medication, as well as a flea and tick control program. Ask your doctor to recommend a plan designed specifically for your pet. Please visit our Fleas and Ticks page for more information.
Out and About
Warmer weather means more trips to the park, longer walks and more chances for your pet to wander off! Make sure your dog or cat has a microchip for identification and wears a tag imprinted with your home address, cell phone and any other relevant contact information.


text:
To download a KML file, visit Resources
GeyserTimes is a 501(c)(3) nonprofit organization dedicated to the acquisition, preservation and dissemination of geyser-related data.
DonateGoogle Play and the Google Play logo are trademarks of Google LLC.
Apple and the Apple logo are trademarks of Apple Inc. App Store is also a trademark of Apple Inc.


text:
Four Roses Single Barrel - a fantastic bourbon |
Four Roses uses 2 mashbill recipes along with 5 proprietary yeast strains to produce 10 different whiskeys. Four Roses Single Barrel uses just one of those recipes, OBSV, which is aged and then bottled from a single barrel (go figure). What does OBSV mean to you? Well, "O" designates that this bourbon was produced at Four Roses Distillery in Lawrenceburg, KY. "B" tells us that this bourbon uses a mashbill consisting of 60% corn, 5% malted barley, and 35% rye. "S" means that it's straight bourbon that's been aged for a minimum of 2 years. "V" means that the "V" strain of yeast was used, a strain that imparts a creamy flavor with hints of fruit and a blast of spice. The bottle typically sells for $39.99 but I once found a ridiculous sale for $29.99 at a local shop and bought nearly all of their stock. It's just that good and I loves me a great deal on bourbon!
Bottoms up, my bourbon brethren! Bourbon Christmas is here!


text:
Photo Of The Week - 18 & 25 August :: Weird Strange and Unusual
I have a collection category I deem "Weird, Strange, and Unusual." The name is an apt description of what can be found in this category. In looking through those photographs I found four photographs that were taken of weddings. I have chosen one of those wedding photographs as the Photo Of The Week. This photograph is classified as unusual, as I have not seen many wedding photographs that picture the bride and groom as well as a child.
Information taken from photograph:
(1) The card measures 4 1/4 in. (h) by 6 1/2 in. (w) and is 0.03 in. thick. The image measures 3 15/16 in. (w) X 5 1/2 in. (w). The sides of the card are scalloped, the corners of the card are square, all with gold edge. The card stock's original color appears to have been cream (matte finish) for the front and back. There is no border line. The ink used to identify the photographer is green.
(2) The photographer's imprint on the front (recto) lists the photographer Ball & Rindahl Studio, Main Street, Grafton, N. Dak.
(3) The back (verso) of the card is blank cream in color.
(4) Background - a rather elaborately painted backdrop.
Card stock and size:
This is a cabinet card on card stock used from 1880 forward. The card stock and size are consistent with photographs produced during the period of time the photographic studio operated its business in Grafton, North Dakota. (See below.)
Henry A. Ball and J. O. Rindahl. Ball was a partner in Ball & Rindahl, Grafton, North Dakota, in 1890; a partner in Ball, Dix & Mead, Ft. Randall, Dakota Territory. The association with Dix and Mead would have been prior to 1890 as the Dakota Territory was divided into the states of North Dakota and South Dakota on November 2, 1889.
Ball and Rindahl had a fifteen year business association. The elaborate backdrop may have been painted by Rindahl as he was a landscape painter (See below).
The clothing of those pictured in the photograph:
The hairstyle of the bride is consistent with the styles worn during the beginning of the 1890s and the end of the previous period. A large section of hair at the top of her head is cut into a curly fringe. The rest of the hairstyle can not be seen in the photograph.
The bride's gown is more consistent with the time period of 1883-1888. The sleeves are skin tight ending just short of the wrist with no cuff. The neckline appears to be a stiff moderately-high standing collar with a collar band underneath just barely visible.
She wears a perfect fitting bodice, a skirt just above floor length with lace trim, a draped overskirt and small bustle. The veil is a filmy full body veil with what looks like the traditional orange blossom trim.
I found a hat similar to that held by the young boy in the Fort Wayne Sentinel, July 02, 1890.
All of this is consistent with the late 1880s early 1890. The cabinet card was most likely produced in the 1880s early 1890.
The photograph and the story it tells:
With the child pictured in the wedding photograph it is a reasonable assumption that this is a second wedding for either the bride or the groom. The child is not positioned in the center of the photograph between the bride and the groom. Instead he stands to the right of the groom, leans on him, and has his hand on the groom's leg. The groom has his arm around the child. The child's attachment appears to be to the groom.
Could the child be the son of the bride? It is highly doubtful. The bride is wearing a white gown. Were this her second marriage her wedding gown would most probably have been grey or lilac. The convention of the time was that a first time bride brought her virginity to the marriage as part of her dowry. That virginity was evidenced by the wearing of a white gown.
The white gown may also be evidence of the family's financial position. Many brides during this time wore their Sunday best as a bridal gown. Purchasing a white wedding dress for a one time use was an expensive purchase. Most white wedding dresses were worn by brides whose family had money.
It is also unusual that the bride is not wearing a wedding ring in the photograph. Was the photograph taken before the ceremony? The most unusual feature of the photograph is what the groom is holding in his left hand, the hand closest to his heart. At first I thought it might be an envelope or the wedding certificate. However, when I enlarged this portion of the photograph I could see the object appeared to be stiff and had rounded corners. The object looks very much like a cabinet card face down. Could the groom be holding a photograph of his deceased wife and the mother of his son?
Many times I have commented that photographs of this period were not left to chance. Symbolism played a large part in what appeared in a studio portrait. Photographs of those who could not be present at an occasion were often seen being held in the photograph. Yes, this could be a photograph of the first wife. I have not seen this in any other wedding photograph (if you have - please comment or email a copy of the photograph to me. I would love to see another photograph like this.)
The bride appears to be very young, quite a bit younger than the groom. Perhaps an older bride would have objected to the cabinet card taking such a prominent place in her wedding photograph. A younger bride might not.
Note: Like coming upon an automobile accident after the dust settles and the cars stop moving, what really happened can be simple or a great surprise, and a look alone rarely determines what happened. The whys and wherefores of a photograph can be equally difficult and often as incorrect. There could be many other plausible explanations for the photograph.
The story of the photographer:
Henry A. Ball
Henry A. Ball was born in Albany county, New York, December 9, 1845. He came to Minnesota in 1866 where it appears from the census he studied photography with his younger brother Jerome. In 1869 he settled in Delano where he established the first newspaper in the town, called the Big Woods Citizen, with Daniel Fish.
In 1870 Henry is living with his first wife Carolyn in Glencoe, Minnesota in the home of William Russell a cheese maker and his wife Lavica. Sometime between 1870 and June of 1879, Henry's wife Carolyn dies. Henry then marries Jennie Webb in Delano, Minnesota, 9 June 1879.
Henry and Jennie are found living in Melrose, Sterns County, Minnesota in a boarding house owned and operated by Peter Wilhelm. Henry's occupation is listed as a photographer, it was in Delano that Henry became a professional photographer.
Henry and his wife Jenny arrive in the Dakota Territory in about 1883. Henry is a partner in Ball, Dix, and Mead in Ft. Randall, Dakota Territory, producing stereoviews probably for the Black Hills View Company of Deadwood, Dakota Territory. The Dakota Territory was divided into the states of North Dakota and South Dakota on November 2, 1889. Dakota Territory was the name of an organized territory of the United States that existed from 1861 to 1889.
In 1883, Henry and Jennie are living in Grafton, North Dakota and operating a photography business. Henry becomes a partner in Ball and Rindahl in 1890, a partnership that lasted for fifteen years.
In 1920 Henry Ball is a 75 year-old justice of the peace. Upon his death in North Dakota, Henry is the state's oldest last veteran of the civil war having served in Company D 7th New York heavy artillery and in the 113th NY Regiment. He was wounded at Coal Harbor.
J.O. Rindahl
September 6, 1895 he was living in Grafton, North Dakota and working as a photographer, but was traveling in Berlin. His passport application states that he was 6 feet tall with grey eyes and light colored hair.
J.O. Rindahl was born on a farm in Stevens, Wisconsin, 10 January 1861. His boyhood days were characterized with vivid dreams of the beautiful pictures he would paint, the marvelous statues he would carve, and the magnificent palaces he would build – dreams of a normal healthy boyhood, in which the soul of an artist was seeking expression.
Being one of a family of twelve, and growing up in the midst of pioneer conditions, dreams had to give way to stern realities of life. In spite of obstacles he managed to get some instruction in drawing from different instructors, but it was not enough to realize his hopes on, so he finally drifted into the photography business, in which he met with no little success.
In 1895, Rindahl went abroad. While there he visited some of the renowned Art Galleries, and saw some of the world's greatest masterpieces in art. They brought back to him in full force the unrealized dreams of his boyhood. He returned to Grafton, and in the moments he could spare from his photography business, and with his talent of no mean order, permeated with the inspiration he had received from his studious travels, he began to shape his dreams on canvas.
in Grafton, North Dakota
The large photograph was taken in Rindahl's studio while he was at work on an altarpiece entitled" "Easter Morning," for one of Grafton's churches. He has painted several large canvas paintings, which adorn the altars of a number of churches in the State; and among the original sketches he has painted, are the subjects: "Too Late," "From the Past," "Alone," The Last Call," "The Witch," and "Scene near Lillehauser, Norway."
Darrah, William C. Cartes de Visite in 19th Century Photography. Gettysburg: Darrah, 1981.
MacPhail, Anna. The Well Dressed Child. Atglen, Pennsylvania: Schiffer, 1999.
McCulloch, Lou W. Card Photographs, A Guide To Their History and Value. Exton, Pennsylvania: Schiffer 1981.
Mace, O. Henry. Collector's Guide To Early Photographs. Iola, Wisconsin: Krause, 1999.
Mautz, Carl. Biographies of Western Photographers. Nevada City, California: Carl Mautz Publishing, 1997.
Nickell, Joe. Camera Clues. Lexington, Kentucky: University Press of Kentucky, 1994.
Palmquist, Peter. Pioneer Photographers Of The Far West A Biographical Dictionary, 1840-1865. Stanford, California: Stanford University Press, 2000.
Severa, Joan. Dressed For The Photographer. Kent, Ohio: Kent State University Press, 1995.
Collections By Minnesota Historical Society, Georgia Historical Society Published by The Society, 1912.
Grafton Centennial, Grafton Carnegie Library, telephone conversation with librarian Sue Vot, 22 August 2008.
1870 U.S. census, McLeod, Minnesota, population schedule, Glencoe, p. 151, dwelling 29 , family 29, Henry A. Ball (Boarder); digital images. Heritage Quest (http://persi.heritagequestonline.com/ : retrieved 16 August 2008); citing NARA microfilm publication T132, roll 7.
1880 U.S. census, Stearns, Minnesota, population schedule, Melrose, p. 550, dwelling 42 , family 42, Henry A. Ball (Boarder); digital images. Heritage Quest (http://persi.heritagequestonline.com/ : retrieved 16 August 2008); citing NARA microfilm publication T9, roll 634.
1900 U.S. census, Walsh, North Dakota, population schedule, Grafton, p. 166, dwelling 376 , family 391, Henry A. Ball (Head); digital images. Heritage Quest (http://persi.heritagequestonline.com/ : retrieved 16 August 2008); citing NARA microfilm publication T623, roll 1233.
1910 U.S. census, Walsh, North Dakota, population schedule, Grafton, p. 199, dwelling 161 , family 164, J.O. Rindahl (Boarder); digital images. Heritage Quest (http://persi.heritagequestonline.com/ : retrieved 16 August 2008); citing NARA microfilm publication T624, roll 1145.
1920 U.S. census, Walsh, North Dakota, population schedule, Grafton, p. 111, dwelling 113 , family 120, Henry A. Ball (Head); digital images. Heritage Quest (http://persi.heritagequestonline.com/ : retrieved 16 August 2008); citing NARA microfilm publication T625, roll 1342.
Wedding by Ball and Rindahl. Cabinet Card. ca 1890. Privately held by the footnoteMaven, [ADDRESS FOR PRIVATE USE,] Preston, Washington. 2007
Ancestry.com. U.S. Passport Applications, 1795-1925 [database on-line]. Provo, UT, USA: The Generations Network, Inc., 2007. Original data: Passport Applications, 1795-1905; (National Archives Microfilm Publication M1372, 694 rolls); General Records of the Department of State, Record Group 59; National Archives, Washington, D.C.


text:
12° /11 storeys inspired by the collective creativity of its neighborhood. The AGO, OCAD The Four Seasons Centre for the Performing Arts. 12° challenges its contemporaries with forward thinking architecture. Intimate in size hut awesome in energy, a boutique building , home to a select few who share a contemporary design aesthetic.
The amenities at 12° are designed for smart, stylish urbanites, by the ultimate urban designers, Munge Leung. A fully equipped fitness studio to work off the day's stress. A beautifully curated private dining room and catering kitchen, for hosting intimate dinner parties.
A private lounge to sit back and toast the end of another day. And, the piece de resistance - a rooftop pool and cabana lounge, with front row views of kaleidoscopic skycapes and the city lights.


text:
- Blogs
Technology, Social Justice and Higher Education
Since the last two years, we at the Centre for Internet and Society, have been working with the Higher Education Innovation and Research Applications at the Centre for the Study of Culture and Society, on a project called Pathways to Higher Education, supported by the Ford Foundation.
Posted by Prasad Krishna at Dec 07, 2011 03:35 AM | Permalink -
Mobility Shifts 2011 — An International Future of Learning Summit
The summit was organised by the New School and sponsored by MacArthur Foundation and Mozilla. It was held from October 10 to October 16, 2011 at the New School, New York City.
Posted by Prasad Krishna at Nov 28, 2011 08:50 AM | PermalinkFiled under: Researchers at Work, Digital Knowledge -
Learn it Yourself
The peer-to-peer world of online learning encourages conversations and reciprocal learning, writes Nishant Shah in an article published in the Indian Express on 30 October 2011.
Posted by Nishant Shah at Dec 02, 2011 01:55 AM | Permalink


text:
Sigma Sigma Sigma // Embroidered Charles River Crosswinds Fleece Zip Jacket
Thank you for shopping with Simply Sisters!
-Relaxed sweatshirt styling
-Soft, ring-spun cotton
-Convenient side pockets
-Quarter zip fleece sweatshirt design
-Antique nickel-finished metal zipper
-Soft 60% cotton/40% polyester
-Banded rib knit cuffs and hem
-Side pockets.
-Embroidered with Sorority in your color choice. If no color option chosen, charcoal grey or white depending on the color of the jacket ordered.
**Please put thread color in notes to seller**
-BULK ORDERS WELCOMED and we offer special pricing!
**All items ship USPS
**All Items ship within 3-5 business days, sometimes sooner!
**All items licensed with Greek Licensing


text:
The mudroom in the Tennessee farmhouse I grew up in was essential for shedding boots dirty from the barn and pastures, but here in suburbia, it would still be pretty nice to have one. Durable walls (board + batten, planks, or tongue-in-groove paneling painted semi-gloss) and floors, ample storage, and place to sit make for a perfect casual entry.
And a designated spot for the dog bed would be nice, too.


text:
JAKARTA, Indonesia (AP) — The U.S. aviation regulator has upgraded Indonesia's safety rating, clearing the way for its airlines to fly to North America nearly a decade after it was barred.
The Federal Aviation Administration said its assessment completed in March found that safety oversight by Indonesia's civil aviation authority complied with international standards.
It said in a statement on Monday that the decision means Indonesian airlines that get necessary approvals can fly to the U.S. and code share with U.S. airlines.
Indonesia, an archipelago of 250 million people that is one of the world's fastest growing air travel markets, has had a bumpy safety record with numerous crashes of civilian and military aircraft and many near misses.
The FAA downgraded Indonesia in April 2007. Indonesian airlines were also barred from flying to Europe from 2007 to 2009.
The U.S. decision is a potential boost for national carrier Garuda, which is the Indonesian airline most likely to start regular flights to U.S. destinations.


text:
When flying I always love to have an empty seat next to me - even better the entire row. Ryanair, however, isn't know to be generous. But by exploiting an interesting peculiarity of their seat allocation algorithm you are able to increase the chances of having more space on your next Ryanair flight.
Most seats on Ryanair are automatically allocated when the passenger checks in. Funnily the seats of row 31 and 32 are allocated as the very last seats. Thus, if the flight isn't fully booked, the seats of row 31 and 32 are the most likely to stay empty.
To get one of those seats you can either buy it, checkin only shortly before the deadline or just board the plane as the last person. Checking in just shortly before the 2 hour deadline should yield the best results as it reduces the likelihood that someone else is allocated to next to the potentially last empty seat. Anyhow, you can always try you look by boarding last from the rear door.
Happy Flying!


text:
After 28 years in the business, we now take a step in to the cyberworld! Welcome to our Pro store on the web. Customer service +46-40-920 200.
▼▼▼▼ Grandselling 4 products right now! "See below" ▼▼▼▼
The majority of our professional qualityproducts are produced by our fantastic factories whom allways trying to progress in the area of Safety, Quality and Inovation:


text:
This Christmas has been lovely. It's the first one where C had understood a bit more and also E's first ever one!
On Christmas Eve, I let C open his Christmas Eve box early in the day then we went to Chris's mums. His sister is a hairdresser so she gave C a haircut so he'd look smart for Christmas. When we came home we had dinner then the two kids had their baths and we watched C's Handy Manny Christmas DVD.
After they went to bed, 'Santa' worked his magic. I bought Chris Jon Richardson's Nidiot stand-up DVD so we ended up watching that before heading to bed ourselves at 4am. C and E woke at 6.30am so that maybe wasn't a good idea!
I came downstairs first with E so I could get the camera ready to take photos of C. Chris was saying "shall we go downstairs? I wonder if Santa has left you any presents?" C's whole body was tensing and Chris said that you could just feel how excited he was. When he came into the living room, his little eyes lit up. He was delighted. He opened his presents first as obviously E didn't know what was going on. He was even painting at 8am!


text:
Well they have finally announced their initial public offering today with a rather low RO 60 million slice of their company up for grabs. There are 600 million 100 baiza shares on offer on the Muscat Securities Market for 102 baizas each. This apparently represents 40% of their paid capital (source).The 2 baiza's are for "Issue expenses". RO 1,200,000 / US$ 3,096,000 to issue an IPO - I'm in the wrong business!
Now, most people don't really care about this but I thought it was interesting as this is the first Islamic Bank to start here in Oman. Ok so Bank Muscat have some Islamic banking services on offer, and Bank Dhofar are looking to get in on the act too, but the boys from Bank Nizwa are the first dedicated Islamic banking crowd to setup up shop here.
The thing that keeps getting me scratching my head is: Islamic banking does not allow for the charging of interest. They make their money by purchasing assets, and then re-selling them to their customer at a higher price. Whether that's a car or a house - the bank buys it, and then allows it's customer to make installments over a period of time for the item. But, here's the rub - the bank can not levy penalties against their borrower for late payment. I'm sure there's more to it but I don't get it - but many people do.
Anyway, I'm digressing. I'd expect there to be a fairly hefty demand for these shares, so if you've got some cash and fancy a punt, RO 102 will buy you 1000 shares in Bank Nizwa. The offering closes on the 22nd May.
More tomorrow.
le fin.