“Once the data has been retrieved and cached locally, we can use it to populate HTML controls in a Web page (a process called data binding), or we can work with it directly using ADO code within the page. In fact, even when using data binding, we’ll often still implement ADO code in the page. This is particularly the case when we want to update the data and submit the changes back to the server.

Data binding uses the Data Binding Agent object that is part of Internet Explorer 4 and higher. When programming in a language like Visual Basic or C++, the special controls that are part of that environment are used to implement data binding instead.

The Web-based Data Binding Agent can provide two types of data binding, either tabular data binding or single record data binding (often called current record data binding). All DSO controls can take part in tabular data binding or single/current record data binding. We’ll briefly summarize the HTML controls that are used in Web pages next, then go on to look at the two types of data binding where they can be used.

Controls that can be bound to a DSO recognize special HTML attributes that provide the connection information they need. These are:

DATASRC - the ID of the DSO that will supply the data, prefixed by a ‘#’ hash character.

DATAFLD - the name of the field in the DSO’s recordset to bind this control to.

DATAFORMATAS - Either ‘TEXT’ (the default if omitted) to display the field value as plain text, or ‘HTML’ to specify that the browser should render any HTML content within the value.”

Read the full article at ASP101.

The author of this article does not have anything deep against Flash. They just feel that that space could be better used in other ways. Here are some of the disadvantages they suggest come with developing a flash introduction for your web site:

“- Increase in file size of the homepage
This is one of the important disadvantages of using Flash intros on your web site - it increases the time the homepage takes to load. I don’t think you will create a Flash intro that has only vector objects. There would definitely be images (raster graphics). This increases the file size of the .swf file which in turn increases the total time taken for the homepage to load fully. A greater offence, is embedded graphics and images that are not optimized or publishing the Flash movie with the lowest compression for images.
Expecting the visitor to first wait while the Flash intro loads and then expecting them to read your animated sales pitches - well, that’s too much of expectation from your time conscious visitors. The question you need to ask is, would you wait for a Flash intro to load on a web site and would you indeed go through text and be enthralled by the images in the intro? I don’t think so!

-Music and sound files in the Flash intro
Music and sound on web sites has been one of my pet-peeves. I am an avid music fan - in fact, I believe that that I listen, therefore I am. But I want to listen what I like and not what is forced onto me. Also, music and sound files embedded in Flash movies increase their file sizes which in turn increases the download time.”

Read the full article at Web Developer Notes and read the rest of the pro’s and con’s of flash, as well as find some resources to develop your Flash into something appealing.

Writing SMIL can in some ways make accessibility seem more difficult. For questions, this web page is helpful. Here is a bit on what they have to say about text timing:

“27.4.5.1. Time containers

Media elements are placed in special time container elements (<par>, <seq>, and <excl>) that define how the media should be played. The <par> element (short for “parallel”) defines a group of elements that play at the same time. The <seq> element defines a sequence of elements that play one after another, in the order in which they appear in the SMIL document.

When media elements are placed in the <excl> time container (short for “exclusive”), only one of those media elements can play at any given time.
27.4.5.2. Time control attributes

SMIL defines a number of attributes for indicating the specific timing of media elements and groups of elements (defined by time containers). Let’s take another look at the narrated slideshow sample from the beginning of this chapter:

<par dur=”15s”>
<audio src=”audio_file.mp3″ begin=”0s” id=”audio_1″ />
<seq>
<img src=”image_1.jpg” begin=”0s” />
<img src=”image_2.jpg” begin=”5s” />
<img src=”image_3.jpg” begin=”10s” />
</seq>
</par>

The dur attribute of in the <par> element specifies that the display of the elements in that group will have a duration of 15 seconds. The dur (duration) attribute can also be applied to specific media element tags. Some media, like audio and video, have implicit durations. Others, like text and images, require you to specify a duration. If you want an image to stay on throughout the presentation, set the value of dur to indefinite. ”

Read the full article hosted by O’Reilly.

Heather Soloman writes about a several important and helpful points in this article on using SharePonint and CSS.
“SharePoint utilizes CSS quite heavily, and it is both a curse and a blessing. Since nearly all of the SharePoint 2003 UI is hard coded in the site definitions, CSS provides one of the best ways to update the UI. But the SharePoint CSS is also pretty unruly and can be quite daunting at first glance. Let’s go ahead and get the numbers out on the table.

For a SharePoint 2003 Portal and WSS install, there are 7 separate style sheets (excluding themes), totaling to 7,403 lines of code and 1,227 style statements. Ouch! Luckily some of that we can slash off pretty quick. Four of the seven style sheets I have yet to ever have to edit to affect a site (Menu.css, OWSmac.css, OWSnocr.css, Paystub.css). The other three are pretty easy:

• SPS.css: SharePoint 2003 Portal style sheet
• OWS.css: SharePoint 2003 Portal style sheet AND Windows SharePoint Services style sheet
• OWSPERS.css: SharePoint 2003 Portal Personal Sites (My Sites) style sheet.
  OWSPERS.css is a combination of a copy of SPS.css and OWS.css with a few things tweaked here and there. You can condense the style statements in OWSPERS.css to something more manageable and less repetitive. I tell you how here.

SPS.css and OWS.css have a few quirks. There are style selectors that are repeated in each. In some cases, the duplicate styles are not connected and control WSS and Portal separately, but in other cases the two are connected and what you have in one can possibly override the other, making for a confusing and frustrating situation. Additionally, the styles may share the same selector, but list different properties in the declaration.

When a portal page is rendered, it pulls in several style sheets, in this order 1) OWS.css; 2) MENU.css; 3) SPS.css.

When a WSS site is rendered, it pulls in the OWS.css style sheet and then the theme style sheet if a theme has been applied to a site.”

Read the full article at the author’s personal blog.

The Synchronized Multimedia Integration Language (SMIL, pronounced “smile”) enables simple authoring of interactive audiovisual presentations. SMIL is typically used for multimedia presentations that can integrate streaming audio and video with images, text or any other media type.

SMIL presentations are described by text files. You can create or edit a SMIL presentation using a text editor, and you can automatically generate a SMIL document using any script language that creates text files. A SMIL document specifies what media elements to present and where and when to present them.

Media elements in a SMIL document are specified by URLs. Media elements can be files such as text files, JPEG images, QuickTime movies or live streams. The URLs that specify the media elements can use any of the common protocols: HTTP, FTP, RTSP, file access and so on.

Your SMIL presentation can use any media elements that QuickTime can play, including still images, audio, text, QuickTime movies, sprite animations, live streams, VR panoramas and VR object movies.

Because SMIL documents are text files, SMIL also gives you a way to automatically generate customized QuickTime movies using a script, such as an AppleScript, PERL or CGI script - anything that can generate text output can create a SMIL document. If you have a script that inserts banner ads into your web pages, for example, you could use the same script to insert the ads into a SMIL document along with a streaming QuickTime movie.

Like the tracks in a QuickTime movie, the media elements in a SMIL presentation can be sequenced, overlapped or offset in time and space.
SMIL Structure

SMIL is based on XML, so it is more rigidly structured that HTML, but it uses the same familiar <tag> and </tag> syntax.

SMIL is different from HTML in that all the tags are case sensitive (always lowercase) and all tags have to be explicitly ended either there are a pair of tags that enclose other elements (<tag> elements </tag>) or a tag is self contained and ends with ” />” (<tag parameters />).

SMIL also differs from HTML because HTML routinely mixes structure and content together in the same document, whereas SMIL normally does not. Where an HTML document contains text to be displayed, a SMIL document would contain the URL of a text file instead.

Like HTML, a SMIL document has a head and a body. The structure of a SMIL file is shown below.

<smil>
<head>
<layout>
<!– layout tags –>
</layout>
</head>

<body>
<!– body tags –>
</body>
</smil>

source : http://www.apple.com/quicktime/technologies/interactivity/smil.html

XPointer allows you to walk the tree of nodes that an XML document is comprised of to address a specific node or nodes. XPointer expands the syntax set forth by XPath to provide a means of creating fragment identifiers, which are used to specify parts of documents. XPointer provides considerably more control over the referencing of XML document data than the hyperlink approach employed by HTML. For example, XPointer allows you to do things such as address an element with a given value within a list of elements of a given type. You use XPointer expressions in XML links by appending them onto the end of URIs with a pound symbol (#), as in the separation between a URI and an XPointer expression. The next few sections break down XPointer into further detail and demonstrate exactly how to create XPointer expressions.

Building XPointer Expressions

The most important component of XPointer expressions is the location path, which is a construct used to describe the path that must be followed to arrive at a node within an XML document tree. Location paths are the building blocks of XPointer expressions, which are evaluated to arrive at a specific location within a tree. More specifically, location paths allow you to traverse siblings, ancestors, children, and descendants of nodes, not to mention attributes. Location paths are broken down into two basic typesabsolute paths and general paths.

Absolute location paths point to a specific location within an XML tree, and therefore aren’t dependent on context. Following are the different absolute location paths defined in XPointer:

*
/ Locates the root node, which is the parent node for the entire document tree
*

id(Name) Locates the element with an attribute ID value of Name
*

here() Locates the node containing the current XPointer expression
*

origin() Locates the sub-resource from which the user initiated a link (used with out-of-line links)

The most important absolute location paths are the root and id() paths. The root path is represented by a forward slash (/), and is often used at the start of an XPointer expression as the basis for absolute location paths. The id() location path is used to locate an element with a specific attribute value.

In addition to absolute location paths, XPointer also defines a rich set of relative location paths. Relative location paths are always relative to some node, which is known as the context node for the path. Following are the relative location paths available for use in XPointer expressions:

*
child Locates child nodes of the context node
*
descendant Locates nodes within the context node
*
descendant-or-self Same as descendant except the context node is also included
*
parent Locates nodes one level above the context node that contains the context node
*
ancestor Locates all nodes above the context node that contain the context node
*
ancestor-or-self Same as ancestor except the context node is also included
*
preceding-sibling Locates sibling nodes that precede the context node
*
following-sibling Locates sibling nodes that follow the context node
*
preceding Locates nodes that precede the context node
*
following Locates nodes that follow the context node
*
self Locates individual context nodes within a list of context nodes
*

attribute Locates attributes of the context node

If you’re totally confused by all this context node talk, don’t worry because it will all make sense in a moment. As confusing as it may seem, the relative location paths in the previous list really are quite useful and are much easier to use than you might think. The next section shows you how to use these location paths to create expressions in XPointer.

Creating XPointers

Seeing a few examples of XPointer expressions can make all the difference in understanding how XPointer is used to define document fragment identifiers. Following is an example of a simple XPointer expression:

child::factoid

This example uses the child relative location path to locate all of the children of the context node that are of element type factoid. Let me rephrase it in a different way: The sample expression locates element nodes of type factoid that are child nodes of the context node. Keep in mind that the context node is the node from which you are issuing the expression, which is a lot like the current path of a file system when you’re browsing for files. Also, it’s worth clarifying that the XPointer expression child::factoid simply describes the fragment identifier for a resource and is not a complete resource reference. When used in a complete expression, you would pair this fragment identifier with a URI that is assigned to an href attribute, like this:

href=”http://www.stalefishlabs.com/factoids.xml#child::factoid”

In this example, a URI is specified that references the XML document named factoids.xml. The XPointer expression is then provided as a fragment identifier, which is separated from the URI by a pound symbol (#). This is the typical way in which XPointers are used, although expressions can certainly get more complex than this.

Read more on Brainbell

The W3C recommendation allows any digital data to be signed, and this includes an XML document, an XML element of a document, and the content of an XML element as particular cases.

When we talk about an XML signature, we are actually referring to an XML document, which contains the Signature (defined in the namespace http://www.w3.org/2000/09/XMLdsig#) as one element (which may be the root element). But the document may also contain other elements, among which the most important are, of course, the original data objects being signed.

Depending on how those data objects relate to the Signature element in an XML Signature document, we consider three different types of XML signatures.

Enveloping: The data objects are contained within the same XML document as the Signature element, and are further included in the Signature element (as sub-elements of Object, for example).

Enveloped: The data object is found within the same XML document as the Signature element, and actually includes the Signature as a sub-element.

Detached: The Signature refers to external network resources, or the data object is within the same XML document as the Signature element, but is a sibling element, or is a sub-element of its sibling element.

Some writings on XML Signature leave readers the impression that this is an exclusive classification of XML signatures; others implicitly suggest that, in enveloping or enveloped signatures, there is actually an Envelop element in the XML document containing the signature; and still others imply that for an enveloping signature, Signature is the root element of the XML document. These are all plainly wrong.

Data Integrity and Message Authentication
The main purpose of XML digital signature is to ensure the integrity of data. RFC 2828, Internet Security Glossary, defines integrity as “the property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner.” Storing or transiting the data together with a checksum can achieve data integrity in this sense. Strictly speaking, XML Signature ensures more than such integrity. It provides support for what RFC 2828 refers to as message authentication, the property “given an authentication code/protected checksum, that tampering with both the data and checksum, so as to introduce changes while seemingly preserving integrity, are still detected.”

source:http://today.java.net/pub/a/today/2006/11/21/xml-signature-with-jsr-105.html

Abstract:
This document lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination.

Status of this document:
This Working Draft of XML Signature Requirements is a very stable result of this Working Draft having been advanced through W3C Last Call. Relatively small changes have been made to clarify the stated requirements during that period. This document will now be advanced as an IETF Informational RFC.

Requirements:

1. Signature Data Model and Syntax:
XML-signature data structures must be based on the RDF data model [RDF] but need not use the RDF serialization syntax. [Charter]
XML-signatures apply to any resource addressable by a locator — including non-XML content. XML-signature referents are identified with XML locators (URIs or fragments) within the manifest that refer to external or internal resources (i.e., network accessible or within the same XML document/package). [Berners-Lee, Brown, List(Vincent), WS, XFDL]
XML-signatures must be able to apply to a part or totality of a XML document. [Charter, Brown]

Multiple XML-signatures must be able to exist over the static content of a Web resource given varied keys, content transormations, and algorithm specifications (signature, hash, canonicalization, etc.). [Charter, Brown]
XML-signatures are first class objects themselves and consequently must be able to be referenced and signed. [Berners-Lee]
The specification must permit the use of varied digital signature and message authentication codes, such as symmetric and asymmetric authentication schemes as well as dynamic agreement of keying material. [Brown] Resource or algorithm identifier are a first class objects, and must be addressable by a URI. [Berners-Lee]
XML-signatures must be able to apply to the original version of an included/encoded resource. [WS-list (Brown/Himes)]

2. Format:
An XML-signature must be an XML element (as defined by production 39 of the XML1.0 specification. [XML])
When XML signatures are placed within a document the operation must preserve (1) the document’s root element tag as root and (2) the root’s descendancy tree except for the addition of signature element(s) in places permitted by the document’s content model. For example, an XML form, when signed, should still be recognizable as a XML form to its application after it has been signed. [WS-summary]
XML-signature must provide a mechanism that facilitates the production of composite documents — by addition or deletion — while preserving the signature characteristics (integrity, authentication, and non-repudiatability) of the consituent parts. [Charter, Brown, List(Bugbee)]
An important use of XML-signatures will be detached Web signatures. However, signatures may be embedded within or encapsulate XML or encoded content. [Charter] This WG must specify a simple method of packaging and encapsulation if no W3C Recommendation is available.

3. Cryptography and Processing:
The specification must permit arbitrary cryptographic signature and message authentication algorithms, symmetric and asymmetric authentication schemes, and key agreement methods. [Brown]
The specification must specify at least one mandatory to implement signature canonicalization, content canonicalization, hash, and signature algorithm.
In the event of redundant attributes within the XML Signature syntax and relevant cryptographic blobs, XML Signature applications prefer the XML Signature semantics.
Comment: Another possibility is that an error should be generated, however it isn’t where a conflict will be flagged between the various function and application layers regardless.

The signature design and specification text must not permit implementers to erroneously build weak implementations susceptible to common security weaknesses (such as as downgrade or algorithm substitution attacks).

4.Coordination:
The XML Signature specification should meet the requirements of the following applications:
Internet Open Trading Protocol v1.0 [IOTP]
Financial Services Mark Up Language v2.0 [Charter]
At least one forms application [XFA, XFDL]
To ensure that all requirements within this document are adequately addressed, the XML Signature specification must be reviewed by a designated member of the following communities:
XML Syntax Working Group: canonicalization dependencies. [Charter]
XML Linking Working Group: signature referants. [Charter]
XML Schema Working Group: signature schema design. [Charter]
Metadata Coordination Group: data model design. [Charter]
W3C Internationalization Interest Group: [AC Review]
XML Package Working Group: signed content in/over packages.
XML Fragment Working Group: signing portions of XML content.

source:http://www.w3.org/TR/xmldsig-requirements

Though you do not have to be familiar with XPath to use the XSLT Mapper, you may benefit from some knowledge of XPath when building advanced expressions in XSLT. On the Web, you will find numerous publications dedicated to XSLT and related topics. Most books on XSLT contain sections on XPath. For a complete description of XPath and how to use it, read the W3C XML Path Language specification. This document is available at http://www.w3.org.

While XPath and XSLT are defined as separate specifications by the World Wide Web Consortium (W3C), XPath functions as a sub-language within an XSLT style sheet. The XPath specification provides a concise and intuitive way to locate and process items in an XML document based on a path through the document’s hierarchy of nodes. XPath uses a compact syntax for use within Uniform Resource Identifiers (URIs) and XML attribute values.

XPath models an XML document as a tree of nodes. XPath uses expressions to refer to different types of nodes—element nodes, attribute nodes, and text nodes—and XPath defines a way to compute a value for each type of node.

XPath expressions contain all the information to address a particular location in an XML schema. XPath expressions can contain location paths, function calls, variable references, unions of sets, comparisons, mathematical operations, and so on, all of which can be used together or independently to return a node set, a node value, or a mathematical or functional manipulation of that node value from an XML document. Additionally, an XPath expression can be evaluated to return three other object types: Boolean results, floating point numbers, and strings.
XPath Syntax

The purpose of an XPath expression is to identify one or more source nodes or to define how result nodes will be populated or modified. To address nodes in an XML document, XPath uses a syntax that is similar to an informal set of directions for finding a particular geographic location. For example, in XPath syntax, instructions on how to get to a particular beach in a park might look like this:

/Canada/BC/Vancouver/StanleyPark/ThirdBeach

Though its syntax is analogous to a file or directory structure, a key difference between XPath and earlier similar languages is that XPath specifies a route, rather than pointing to a specific set or sequence of characters, words, or other elements.

Similarly, if you wanted to locate the price of a particular line item in a purchase order, your XPath location path might look like this:

/PurchaseOrder/item[name=’Leaf blower’]/price

A basic XPath expression can consist of one or more location paths. An XPath location path is essentially a description of how to get from the current location to another one. It is made up of a series of location steps separated by a delimiting character. A location step can be composed of an axis, a node test, and a predicate, which are expressed as follows:

axis_name/node_test[predicate]

The axis specifies a route through the schema tree starting from a particular context node. The route is defined in terms of a list of nodes reached from the context node. The node test then selects a set of nodes using the selected axis. Expressions use predicates to further filter the set of nodes selected. For example, the following expression would return the Price child of the second occurrence of PurchaseOrder/Item within an XML document:

PurchaseOrder/Item[2]/Price

If a predicate is used to filter a node in an XPath expression, the node to which the predicate applies is known as the context node. You can access the context node directly using the expression “.”, which is the value of the select attribute within a <xsl:value-of> statement.

In all of the above examples, the XPath expressions are relative to the starting location. In XPath, the current node is the starting point where the location addressing begins at runtime. A node becomes the current node when it is processed using an <xsl:apply-templates> or <xsl:for-each> statement. You can access the current node directly using the current() function. If within an XPath expression, a predicate is applied to the current node, then the current node is also the context node and you can access it directly using the expression “.”.

In addition to the context node, current node, and location paths, XPath applies two other key concepts: the hierarchical tree structure in XML documents and logical relationships, such as ancestor, attribute, child, parent, and self, which are defined in the XML Information Set specification from the W3C.

source : http://developer.capeclear.com/7_beta/help/index.jsp?topic=/com.capeclear.eclipse.studiohelp/studio/wstransform-introductiontoxpathandxslt.html

Alex Homer shares much information in this multi-part article on enhancing the accessibility of your ASP .Net 2.0. The first part of this series deals with accessibility in general: “Web pages today are very different from the original vision of the World Wide Web pioneers. They saw it as a sharing and publishing environment for scientific information, rather than the public network offering online retailing, the source of references material on every topic under the sun, and the general entertainment arena that it has now become. Wide public access and the continuing commercialization of the Web have brought changes in the type of content it offers. The most remarkable change has been the move away from the functional, mainly text-based, types of pages. Today, the Web is ruled as much by designers and graphic artists as by developers and network specialists.

Web pages have become more complicated. No longer is it permissible for your company “home page” to contain a picture of your offices and a simple text menu for the services you offer. Now you have to have drop-down or pop-up menus with myriad links, graphics (preferably animated), and dozens of headlines that lead to press releases, new product details, or testimonials of your services.

All this is fine if your visitors can look at the page and easily identify the areas that interest them, or scan up and down the links to other pages looking for what they want. And, should they stray to the wrong page, it’s usually pretty obvious from a quick glance. However, things are nowhere near this easy for all visitors.

A proportion of visitors will have difficulties with most current Web sites, which are designed almost without exception for people who have reasonable eyesight and are using a pointer device such as a mouse, trackball or graphics tablet. There are many people to whom one or both of these conditions cannot be applied. Often they will be using a specially designed user agent, or maybe a simple text-based browser. Or it might be aural page reader, which reads the contents of pages out loud, or a Braille reader that translates the text into a format that can be read by fingertip on a special output device.

For all these types of device, even the most basic Web site or Web application (designed and tested only in a modern graphical browser such as Internet Explorer) can be hard to read. At best, navigation through the site can be challenging, and certain parts of the content may be meaningless. Graphics and pictures won’t be displayed on text-based devices, while color-blind users may not be able to distinguish between the different lines or pie segments in your charts. At worst, it may be completely impossible use online forms, to even access parts of the site at all.”

Read the full article hosted by 15 Seconds. Information specific to .Net is found in the second part.