My wife is a tenderfoot in the Web development arena. Imagine how surprised I was when, after just earning her certificate in Web design, she sprung this revelation on me: “HTML is going to be replaced by SMIL.” I thought, “Who do you think you’re talking to, sister?”

I reckon I was most put off because I wasn’t sure I knew exactly what SMIL was.

Structured Multimedia Integration Language (SMIL) is to multimedia developers what HTML is to linked-content developers. I remember reading about SMIL a few years back, but I recall thinking that it sounded like a play by Real Networks for more market share. Real Networks, after all, was a big contributor to the SMIL 1.0 specification. Microsoft was involved too, but it jumped out of the saddle before the gates were opened, claiming the SMIL specification was too green.

I think I blew off SMIL when I read that Internet Explorer 5.5 would support HTML-TIME, also a multimedia synchronization language. After researching SMIL more thoroughly, I suddenly felt as dumb as a parakeet with a tracheotomy. It turns out that HTML-TIME is based on SMIL 2.0. The main difference is that HTML-TIME is aimed at presenting multimedia within a browser, whereas SMIL is a stand-alone specification whose players need not understand HTML.

The lines have been drawn. Companies with a browser focus such as Microsoft and Macromedia — support HTML-TIME. Those with a stand-alone-player focus — like RealNetworks, Apple, and Oratrix — support SMIL. For developers, it doesn’t matter which approach wins the day. The synchronization concepts are nearly identical and the syntax will eventually be based on SMIL 2.0.

SMIL has grown substantially from its first incarnation. SMIL 2.0 describes modules for timing, animation, layout, linking, media objects, transitions, and more. The basic media types supported are animation, audio, image, text, text stream, and video. Some tag names from the 1.0 release have been updated or deprecated to make SMIL 2.0 compatible with the document object model.

So why Should anyone give a heap of beans about SMIL? SMIL makes for compelling content. Video presentations on the Web basically stink today. A two-inch video popup, for example, has little visual impact. Animation files, a la Macromedia Flash, on the other hand, can generate impact and motion. Integrate the two techniques within a single presentation and you are getting somewhere.

Both animation and video suffer from some key problems, however. Imagine internationalizing a video. You might have to dub the video in six languages and make it available in three bandwidth-optimized versions. Eighteen files just to support a video clip. If you want to add optional captions for the hearing impaired, you’re up to m36 files.

Read the full story on Find Articles

XSLT allows you to create formatting structures which interpret and modify the existing XML elements. Learn about the syntax of XSLT elements, how the namespace attribute differs depending on the browser in use, and how to transform original XML elements.

XSL or eXtensible Stylesheet Language began life in much the same way as XML — as a submission to the W3C. The W3C quickly released several working drafts before the final working draft was released in 2000. It shared some common design goals with XML, namely:

• A quick design process
• Transparency to users and developers
• Ease of use
• Avoidance of optional features
• Suitable for use over the Internet

As with XML, these goals were largely met. In October 2001, XSL was split into three separate working specifications by the W3C: XSLT, which is XSL Transformations, XSL-FO, which is XSL Formatting Objects, and Xpath, which defines parts of documents and linking structures. XSL-FO is now formally known as XSL. We will focus mainly on XSLT in the article, but XSL (XSL Formatting Objects) will be looked at briefly towards the end.

Every well-formed XML document has a tree-like structure consisting of parent and child elements. What XSLT does is allow you to create formatting structures which interpret and modify the existing XML elements and can output the results of these structures to HTML (or other output media). It allows you to transform a source tree into a result tree of XML elements.

Both XSLT and XSL must be well-formed documents, and as such XSLT documents must begin with the XML declaration. Following this comes the XSL:stylesheet element, which is the root element of the document and should contain at least the namespace declaration.

The transformation rules are then added as child elements of the root element. XSLT stylesheets are constructed using template rules that match one or nodes in the XML source documents logical tree. These template rules then create instances of fragments of the result tree. The XSLT result tree is composed of the hierarchy of nodes in the XML document to which it is applied.

The syntax of all XSLT elements is the same:

<xsl:tag-name attribute=”value”>
</xsl:tag-name>

These elements are reserved in the namespace URI that is set in the documents root element. Template rules also follow a similar syntax:

<xsl:template attribute=”value”>
</xsl:template>

There are many template element attributes, some of which we’ll explore during the course of this article. As an example of XSLT techniques, we will be creating a stylesheet document that transforms the XML document created in my previous XML article.

To start with then, as stated above, XSLT documents should be well-formed XML documents, so you start with the XML declaration:

<?xml version=”1.0″?>

You then need to add the root element of the stylesheet document with the namespace declaration:

<xsl:stylesheet xmlns:=”http//www.w3.org/TR/WD-xsl”>

At this point it should be noted that the namespace attribute for XSLT documents differs depending on the browser in use. The namespace declaration used here is for IE5+ browsers. If IE5+ will not be used the following namespace declaration can be substituted:

<xsl:stylesheet xmlns:=http://www.w3.org/1999/XSL/Transform>

Source : DevArticles

Luther Stanton presents some straight forward answers to Object Data Binding questions within the .Net framework: “Data binding is not a new concept for developers. It has been an essential part of any application; it is the most basic way to move information between an application’s end users and the processing logic. Many times this has been done by brute force, manually writing code to move values between properties on objects and GUI elements such as text boxes, data grids, and check boxes. What is new, however, is that the .NET Framework provides a rich set of functionality out of the box. Specifically, the framework provides a great deal of motivation to start using data binding within applications:

• A “set and forget” approach to maintaining synchronization between GUI controls and object properties
• Built in type conversion, such as mapping a decimal type property on an object to the “text” string type property on a text box
• A built in system based on delegates and events to “watch” objects for property changes
• Building of rich UI experiences by allowing objects to manage the GUI control properties with minimal developer interaction- such as not enabling a save button until values are changed
• A rich set of events to allow developers to override the default parsing and formatting of values into the assigned control properties
• Built in data type validation of controls, such as ensuring only valid dates are entered in a text box tied to a date time property on an object.

In my experiences, the built-in data binding functionality has not been utilized to its fullest potential. I still see a lot of clients continuing to write large amounts of code to marshal data between the GUI and application objects. Perhaps it is lack of realization of what .NET has to offer or a lack of understanding of how.NET manages data binding behind the scenes. It is my hope to eliminate both of these hurdles with this article and begin to open up the possibilities of data binding to your applications.”

You can read the full article presented by 15Seconds.com

“So What is a DTD?

The tags in the HTML language must be defined somewhere, right? They are defined in the DTD, which stands for Document Type Definition. In a DTD for HTML, all the HTML tags are defined. Everything is defined in the DTD — the tags, the attributes, the possible values they can hold. Think of the DTD as the HTML tag dictionary: it lists all the tags, what they mean, and how they relate to each other.

Also, there are different DTDs because there are different versions of HTML:

• HTML 4.01 Strict
• HTML 4.01 Transitional
• XHTML 1.0 Strict
• XHTML 1.0 Transitional
• and several more. “

Read thefull tutorial from DHTMLdev.com. This document is available in PDF format for saving and reference.

We’ve provided examples below that show that CSE HTML Validator can find problems and issues that other syntax checkers and validators (such as the popular W3C HTML Validator) cannot find. The testing was done with recent versions of CSE HTML Validator. Validate the source HTML document using the W3C HTML Validator and see how many problems/issues it misses (it misses ALL of them as of July 9, 2007). Even with all these issues, the W3C validator says that you may want to place an icon on your page to show your readers that you’ve taken the care to create an “interoperable” web page. We don’t consider a page with so many problems “interoperable”, and neither should you.

Why does it miss these issues? A DTD validator like the W3C validator and other validators claiming to be based on real SGML parsers, are technically incapable of finding certain problems because they are more limited in the number of problems that they can check for. These validators are only concerned about strict adherence to the specifications. They consider many things supported by Internet Explorer and other browsers illegal. They also consider bad attribute values that don’t work in popular browsers to actually be legal (like width=”really wide”). These methods of checking for problems do not reflect upon “real-life” situations.

CSE HTML Validator is designed to be a “real-life” validator. As such, it is not limited to adhering to strict HTML specifications. Instead of generating errors for issues that are fine in the real-world, CSE HTML Validator understands them. Instead of not generating errors for bad attribute values, it reports them. CSE HTML Validator can find many more problems or potential problems than other syntax checkers and validators can find. If you do wish to adhere to the standards as closely as possible, then CSE HTML Validator will help you do that as well, with its “standards compliant check”. Also, CSE HTML Validator Std/Pro v8.0 and above now include a DTD based validator for when you’d like to use one.

In addition to all of the above, CSE HTML Validator also checks CSS, links, and spelling. It also checks for accessibility issues. If you’re concerned about search engine rankings (and you probably are), then you’ll be glad to know that CSE HTML Validator also generates messages that may help you increase your search engine rankings.

Source : http://www.htmlvalidator.com/htmlval/whycseisbetter.html

Adrian K. writes a fantastic article about how to integrate XML, AJAX, and C to create an error catching system. The short story, in their words, goes: “It’s kind of scary realizing that should your JavaScript fail, the only way you’ll know is if some kind user lets you know. We’ve all seen “object x is undefined” errors and so on, how many times have you reported the error to the webmaster? It’s easy for these problems to go unnoticed for prolonged periods of time.

I have recently been getting to grips with ‘AJAX’ techniques, and had a magic light-bulb moment when I realised that by using a combination of AJAX and C#, we can do away with reliance on users, and log the errors automatically ourselves.

The basic plan of attack is as follows:

• Catch the client side JavaScript error. Encapsulate it in XML.
• Send it to the server via an XmlHttpRequest (AJAX)
• Catch the XmlHttpRequest on the server by using a .Net HttpHandler.
• Save the error information to a database, file or email.”

Read the full detailed instructions through the Code Project Network

As web standards advocates, many of us participate in numerous online communities such as mailing lists, forums, newsgroups and even blogs (both our own and comments on others). In these communities, we often encounter beginners who are either just starting out with HTML, or have been doing HTML for a while, but are new to the concept of developing with standards.

Invariably, such beginners face the eternal question of HTML or XHTML; and today, I intend to answer this question (as it applies to beginners) once and for all. For experienced users, the answer may be different, this only applies to beginners and to those of us teaching them.

I don’t particularly want to start up the XHTML vs. HTML debate again, nor simply reiterate that XHTML as text/html is extremely harmful; and I must stress that both HTML and XHTML have their uses and it’s important to use the right tool for the job. But for beginners, there needs to be a clear answer with a clear learning path, and those of us teaching them need to be united in our position. For if beginners are hearing different answers from different parties, only confusion will result and we may end up losing them to dark side of the force forever.

Let me start off by saying that XHTML is not for beginners. We must start with HTML and have a clear learning path towards the future with XHTML. It has been argued, that since the future lies with XHTML (although that is yet to be seen), we should be teaching XHTML from the ground up. That sounds nice in theory, but the reality is that we’re still teaching in a predominately text/html environment, and the fact is: trying to teach XHTML under HTML (tag-soup) conditions is like trying to teach a child to swim by throwing them in the deep end and not realising they’re drowning until it’s too late. When it comes to XHTML: there is far too much for a beginner to learn, not to mention the significant issues of browser support, that we must simply accept that they’re not ready and teach them HTML instead.

XHTML is not merely HTML 4 in XML syntax, it comes packaged with all the XML handling requirements as well, with great big “Fragile” and “Handle with Care” stickers on the front of the box. Despite all the myths surrounding the ability to use XHTML as text/html and then simply make the switch to XML when browser support improves, there is significant evidence to show that XHTML developed in a text/html environment will not survive the transition to XML.

The sheer number of tag-soup pages claiming to be XHTML are a direct result of pushing it upon newcomers while leaving out all the extremely important details, most of which they won’t understand yet anyway, but do actually need to learn before using it. I won’t go into the details here, but these issues with XHTML include, among others, the following; and I guarantee that if you ask a beginner (who learned XHTML under HTML conditions) about any of them, they’ll look at you blankly, without a clue what your talking about.

ead more on: http://lachy.id.au/log/2005/12/xhtml-beginners

“‘A web of data’ is a well conducted explanation of the Semantic Web. From the beginning, Tim Berners-Lee and the W3C expected the Web to become a place that allows humans and machines “to start off in one database, and then move through an unending set of databases which are connected not by wires but by being about the same thing.” In the Semantic Web, data is annotated with unambiguous definitions and connected by meaningful links. The entire Web thus becomes a network of machine-processable data (including links, which are also data in another form). The Semantic Web is a web of data.

But this explanation of the Semantic Web causes problems when people start to build the Semantic Web based on this view. Typically, two questions are raised:

1. Who will hold the authority on the ultimate explanation of Web data?
2. Why should ordinary Web users contribute to a web of data? “

Each of those questions is linked to more information, giving this entire article a rare depth. Read the full article Abandon Babel, Welcome Society: The Philosophy Behind Semantic Web Approaches and learn more.

In the first column of this series, we presented a high-level WSS4J API, which we wish to implement in this series of columns. In the second column, we discussed the various Java components we are going to use in implementing the WSS4J API. The most important component is XML Security Suite for Java (XSS4J) from IBM alphaWorks. The second column also demonstrated how to use XSS4J for XML encryption.

In this column, we will use the XSS4J concepts discussed in the previous column to implement the XML encryption features in our WSS4J API.

Before we start the discussion, we would like to point out a name clash issue. There’s an open source Web Services Security project at SourceForge.net (recently moved to Apache’s web site) that shares the same WSS4J name. The WSS4J API we are developing in this series of columns is purely for educational purposes and aims at demonstrating the use of WSS in Java applications. The WSS4J open source project at SourceForge (now at Apache) is an independent project and is not part of our effort.

A WSS Message Before and After XML Encryption:

We are going to add support for both symmetric and asymmetric keys in our WSS4J API. Listing 1 shows a simple SOAP message we will use as sample input to our XML encryption process. We will encrypt a portion of Listing 1 to demonstrate the working of our WSS4J API.

We are going to perform three types of XML encryption. Listings 2, 3, and 4 are three WSS messages that show the outcome of our encryption process. Listings 2, 3, and 4 are slightly different from each other. As we have already covered the details of WSS format in our Web Services Security series (especially in Part 4), we will not go into the details of WSS format. Here we will only highlight the differences between Listings 2, 3, and 4:

Listing 2 shows the following:

1. If you look at the contents of the SOAP body in Listings 1 and 2, you will see that the first Parameter element of Listing 1 has been replaced by an EncryptedData element in Listing 2. The EncryptedData element contains the encrypted form of the Parameter element. The encryption algorithm used for this XML encryption is triple DES as specified by the EncryptionMethod child of the EncryptedData element.
The EncryptedData element in Listing 2 does not contain any key information. The corresponding key information resides inside the wsse:Security element in the SOAP header, which contains an EncryptedKey element. The EncryptedKey element wraps a symmetric triple DES secret key in encrypted form. Notice from Listing 2 that the EncryptionMethod used to produce the EncryptedKey is RSA and the key used for this RSA encryption is the tour operator’s public key. We covered the details of such encrypted keys in Step 2 of the Using XSS4J for XML Encryption section in the second column.
How do we relate an EncryptedData element with its corresponding key used for encryption? Look at the ReferenceList element inside the EncryptedKey element of Listing 2. The ReferenceList element has a child element named DataReference, whose URI attribute points to the EncryptedData element we produced using the encrypted key.

The EncryptedKey element is a security token in WSS terms. Although the XML encryption specification simply calls it an encryption key, the WSS specification talks about abstract (or more general) tokens. This means we can treat cryptographic keys as a type of security token. Therefore, while implementing WSS, we will treat an EncryptedKey structure as a type of token and call it an encrypted key token.

Now look at Listing 3, which is a very slightly modified form of Listing 2. The only difference between Listings 2 and 3 is that the EncryptedData element in Listing 3 contains a KeyInfo element, which wraps a SecurityTokenReference element. The ecurityTokenReference element has a Reference child element, whose URI attribute refers to the wsu:Id of the EncryptedKey that was used to produce the EncryptedData.

If there are more than one EncryptedData and EncryptedKey elements in a WSS message, then it is computationally more expensive to find the EncryptedKey corresponding to a particular EncryptedData structure in Listing 2 as compared to Listing 3. That’s because in Listing 2 you have to look into the ReferenceList elements of several EncryptedKey structures until you find the required EncryptedKey structure. On the other hand, if you have to find the EncryptedData structure corresponding to a particular EncryptedKey Listing 3, you can read the URI attribute value of the Reference element and jump directly to the required EncryptedKey structure.

We will call Listing 3 as an encrypted key token with cross reference.

Now look at Listing 4, which shows the following:

1. The EncryptedData element in Listing 4 contains a KeyName element, which specifies the name of the key used for encryption. Here we are assuming that the recipient of this message can locate the actual key corresponding to this name. Therefore, we are not concerned about how an application will map a key name to the actual key.
2. There’s no EncryptedKey element inside the wsse:Security header. Instead we just have a ReferenceList element that refers to the EncryptedData element inside the SOAP body. This type of ReferenceList element does not specify the key used for producing the EncryptedData element. This ReferenceList only specifies the order in which different actions take place in the header (e.g. if you encrypt and then sign a portion of a message, the ds:Signature element will appear before the ReferenceList element. For details please refer to the discussion accompanying Listings 7 and 8 in the fourth article of my Web Services Security series).
We will call this ReferenceList element a reference list only token.

We will implement the first two types of tokens (encrypted key token and encrypted key token with cross reference) in this column and the third type (reference list only token) in the next column of this series.

Read the full article on XML.com

If you’ve been looking for a way to get a custom scroll bar onto your web page, without worrying about all the clunk of browser compatibility, you might want to check out the FleXcroll Customizable, Standards Compliant ScrollBar by Hesido.

This is what the author, Hesido, had to say about the features of their scrollbar: “fleXcroll supports mouse-wheel and keyboard scroll (from version 1.5.0), and text selection aid (from version 1.7.5) so people can text-select overflowed contents, making it behave almost the same as (and in some cases better than(!)) OS default scroll bars. Even with all its features, fleXcroll will not be able to satisfy some users, so that’s why I made it fully unobtrusive, making it a solution that allows content to be accessible when javascript is turned off, and it does a pretty good job of behaviour abstraction from html: you write your html like the way you are used to, except there are a few things you need to be careful about, and fleXcroll handles the rest.

…

Opera 8.5, Opera 9, Firefox 1.5, Firefox 2.0 for PC and MAC and Linux, Webkit (MAC), IE5, IE5.5, IE6, IE7 has been tested to work with fleXcroll. IE for Mac does not support fleXcroll, it is a discontinued product that has many scripting bugs, and it is blocked from using fleXcroll so IE users on Mac can also browse your content.”

The scroll bar script is available for free download and use on non-commercial web pages. Commercial web sites are asked to pay a usage fee. Information on accessibility support, CSS notations, and Javascript information are all included on the author’s web site.