Annotation is the process of associating metadata with data. This article presents a Web services API intended as an industry standard for client-server systems designed to facilitate the structured annotation of heterogeneous data. The author presents the goals of the Annotation Web services API and then discusses how those goals motivate the data model around which the API operates. The author also discusses 29 methods that comprise the API including two examples of possible sequences of API calls to create and retrieve annotations.

The Annotation Web services API is an implementation-neutral set of SOAP-based Web services calls intended as an industry standard to facilitate the interoperability of clients who wish to enable annotations and servers that store annotations and implement the API. The Web services Definition Language (WSDL) formally defines the syntax of the API. There are accompanying semantics in another document. This article explains the motivations behind the API’s design, as well as an overview of the API. You should consult the WSDL and accompanying semantic documentation for more information (see the Resources section below for links).

The word annotation has many different meanings depending upon the context and audience. Regardless of these differences, every annotation is essentially some metadata associated with some target data. The target data itself can vary from a table in a relational database, to a word processing document, or to the topic of what to cook for dinner tonight. The corresponding annotation might be an entry in another database table, a comment within the document, or a sticky note on the front of the refrigerator. Annotations are important when large amounts of data are created, shared, and examined. For example, the life sciences industry and the legal profession both make heavy use of annotations.

Everything but the refrigerator

Because of the substantial generality of annotations, the scope of the design must be narrowed in order to arrive at a useful and manageable Annotation Web services API. To accomplish this, the goals of a system must be enumerated based upon the Annotation Web services API and then derive the data model and API calls from those goals.

Annotate arbitrary digital data

The primary goal of the Annotation Web services API is to enable the annotation of any arbitrary digital data. Please note that the type, size, structure, or content of the data is arbitrary. For example, the same Annotation Web services API methods facilitate annotating both legal briefs and scientific experiment results.

Annotations stored out-of-band

The API should acknowledge the intrinsic existence and identity of data objects regardless of their names, locations, or any properties other than their contents. In other words, an annotation that you create on a memo on your local hard drive should be visible to your coworker with his or her own copy of the memo, despite potentially differing meta-information such as file name or timestamp. To accomplish this, the Annotation Web services API must encompass a model in which the annotations are stored separately from target data objects and in which data objects’ identities can be determined independently of file meta-information.

Structured annotations

Many applications include annotation functionality that follows the “sticky note” paradigm. Such annotations are better referred to as comments, as they consist only of free-form text entries. Even when centrally gathered, these unstructured comments are difficult to search or data-mine effectively and efficiently. Therefore, one goal of the Annotation Web services API design is the support of structured annotations — annotations containing information that conforms to a particular structure. Because a free-form text entry is simply one particular annotation structure, this design goal does not preclude unstructured annotations.

Other design goals

Several other goals also drove the design of the Annotation Web services API. Access control must be included to allow for private and semi-private annotations. The API must also facilitate bidirectional access between the annotations and the target data. The API also allows for maximum configuration, flexibility, and extensibility by implementors.

Source: IBM

The www-p3p-policy mailing list gets a steady stream of messages from frustrated Webmasters who are trying to P3P-enable their Web sites and have run into difficulties. In some cases these Webmasters do not understand fundamental concepts about how P3P works. However, in many cases they actually have come pretty close to successfully P3P- enabling their sites, but something is still not quite right. In this article I review some troubleshooting strategies and list some of the frequent mistakes I have seen people make. For more detail about the entire process of P3P-enabling a Web site as well as examples of how to write policies that cover a variety of common Web site scenarios, check out my book, Web Privacy with P3P.

Test, Test, Test

The first thing you should do after P3P-enabling a Web site is to test it to make sure your P3P implementation is correct and that it works. This should be done using the W3C’s P3P Validator and using at least one P3P user agent.

You can use the P3P Validator to check to make sure your P3P files are syntactically correct and placed in the appropriate location on your Web server. If the validator reports any errors, read them carefully, and work through them one at a time until you get a successful validation report. Unfortunately, bugs are still being found in the validator from time to time, so in some rare cases, valid sites do not validate, or errors are not caught. Therefore it is a good idea to review the list of known bugs on the validator Web site and check to see if any of them may be applicable to you. If you have configured your Web server to issue P3P headers, you need to make sure that your server is actually issuing those headers. The validator report will indicate whether or not the validator received any valid P3P headers from your Web site.

Once you have validated your site, you should test it with at least one P3P user agent, and, if possible, with all P3P user agents that visitors to your site might be using. Right now I would advise Webmasters test their P3P implementations using IE6, Netscape 7, and the AT&T Privacy Bird. The first thing to test with all three of these P3P user agents is whether they can produce a human-readable summary of your site’s P3P policy. You can get that summary with Privacy Bird by clicking on the bird and selecting Policy Summary from the About This Site menu. IE6 will produce a policy summary if you select Privacy Report from the View Menu. In Netscape 7 you will need to go to the View menu, select Page Info, go to the Privacy tab, and click on the Summary button.

Besides verifying that all three user agents can produce a policy summary, you should also read the summaries and make sure they accurately reflect your privacy policy. This is a good way to spot any errors you may have made when encoding your privacy policy in XML. While we have found some rare cases where valid P3P policies are not properly displayed, or not displayed at all by one or more P3P user agents, generally, if your policy does not display properly, it indicates there is something wrong with your policy. If you make changes to your policy, you may need to clear your browser’s cache or the Privacy Bird’s cache before you see an updated policy summary.

Read entire article on: http://www.oreillynet.com/pub/a/javascript/2002/11/19/p3p.html

SMIL (pronounced as “smile”) – Synchronized Multimedia Integration Language is an XML application defined by World Wide Web Consortium (W3C). SMIL 2.0 [1] has just been released as the W3C recommendation on 7th August 2001. The main design goal as stated by W3C is to define an XML-based language that allows you to write interactive multimedia presentations as well as allowing you to reuse the SMIL syntax and semantics in other XML-based languages such as XHTML. SMIL is an XML-based and vendor neutral markup language that allows you to build interactive multimedia presentation by integrating different media such as audio, video, images and text. It is a powerful markup language that allows you to control what, where, when and how you want the media objects to be in your multimedia presentation. For instance, you may want to position and synchronize the audio object with the image and text or you may want to play a video clip two seconds after an audio narration ends.The specification of SMIL was first publicly released in November 1997 and SMIL 1.0 was published by W3C in June 1998. It signifies the cross-industry agreement on a wide range of features for putting multimedia presentations on the Web. Various working drafts were announced since then and SMIL 2.0 was finalized in 2000. In June 2001, SMIL 2.0 was released as a proposed recommendation and shortly after that, it was officially announced as W3C recommendation on the 7th August 2001. There are a number of available SMIL players such as Oratrix’s GRiNS [2], RealNetworks’s RealPlayer [3], Apple’s QuickTime [4] and Microsoft Internet Explorer 5.5 [5]. Among all, Oratrix’s GRiNS player supports W3C SMIL 2.0 proposed recommendation syntax and semantics. Microsoft acknowledges SMIL by introducing its HTML+TIME approach. Its SMIL-flavored Timed Interactive Multimedia Extensions (HTML+TIME) is to integrate SMIL 2.0 modules with XHTML modules. Microsoft’s Internet Explorer 5.5 supports a number of the SMIL 2.0 draft modules such as Timing and Synchronization and its Internet Explorer 6.0 public preview supports many of the SMIL 2.0 modules.

Why SMIL ?

There are many significant advantages of adopting SMIL. Before, we embark on the detail of SMIL, I would like to highlight some of the obvious advantages of using SMIL:

Declarative and vendor-independent

SMIL is a W3C recommendation. It is an open, vendor independent, easy-to-use and declarative language for multimedia presentations on the Web. In fact, it uses a text-based format so that you can even create it with a text editor.

Integration of multiple media

SMIL integrates multiple media such as audio, video, images and text into a single multimedia presentation. As the name Synchronized Multimedia Integration Language suggests, a SMIL document itself does not contain these media. It integrates them by referencing to the content you may have created e.g. streaming video in RealSystem.

Powerful and elegant spatial layout

SMIL provides easy-to-use and powerful spatial layouts such as regions, multiple windows layout and hierarchical layout for multimedia presentation on the Web. You could declare a set of regions on which media objects are rendered. This will determine how the media objects are positioned on an abstract rendering surface.

Temporal layout by timeline control

One of the significant advantages of SMIL is timing and synchronization. SMIL provides a powerful way of specifying multimedia content. It provides synchronization elements such as <par>, <seq> and <excl> so that you can coordinate and synchronize the presentation of media over a specified timeline. For instance, you could specify the audio narration begins after an image is displayed for five seconds.

Selection and adaptation

SMIL provides powerful content control to facilitate selection and adaptation to the users such as the language used, to the layouts such as the screen size in different devices, and to the environment such as the bandwidth supported. For instance, it provides “test-attribute” mechanism so that the multimedia presentation’s bandwidth requirements are optimized based on the speed of your computer’s connection to Internet. Different media files are used in the multimedia presentation according to the types of connection such as slow 28.8 Kbps dial-up connection or high-speed T1 connection.

There are many potential SMIL applications in various areas. These application areas include infotainment like Internet TV and multimedia presentation, interactive training like e-learning and on-line training program for corporate and institution, multimedia slide show for photography and travel industry, interactive and dynamic product catalogue presentation etc.

How to Start ?

As SMIL is text-based, you only need a simple text editor to create a SMIL document. However, there are also SMIL authoring tools available to assist you in putting various media objects in a SMIL document so as to produce a multimedia presentation easily. Some of the tools available are: GRiNS authoring tools by Oratrix, RealSlideshow by RealNetwork, EZer by SMIL Media, HomeSite by Allaire etc. In this tutorial, you only need to use a simple text editor. The following code shows the outline of a simple SMIL document:

<smil>
<head>
<!— optional header section for presentation information
e.g. meta info., layout —>
<meta name= . >
<layout>
<!— layout specification —>
.
</layout>
</head>
<body>
<!— required SMIL body section containing
media objects, synchronization elements etc. —>
.
</body>

</smil>

Since SMIL is XML-based, it follows XML well-formed rules such as case sensitivity, matching opening and closing tags etc. A SMIL document is created with file extension ‘smil’ or ‘smi’. It begins with <smil> elements and it comprises two main sections, the header section (i.e. <head>. </head>), and the body section (i.e. <body>. </body>). It is finally ended with a </smil> element.

The header section may include the following presentation information:

• Meta-Information: It is used to describe the SMIL document such as presentation title, author name, copyright information etc.
• Layout Information: It specifies the presentation layout that allows positioning of media objects on the visual rendering surface. It is used to define a set of regions on which media objects will be positioned. In other words, it describes where the media objects are to be presented.
• Author-Defined Content Control information: In SMIL 2.0 [1], you could define your own (i.e. customized) content control information to be used in the document body to facilitate adaptation and selection. We shall not discuss this feature in this jumpstart tutorial. However, you could refer to the SMIL 2.0 specification [1] for more detail.

Continue to read full story at Micosoft Apress

Think about how many times a day you use forms, electronic or otherwise. On the Web, forms have become commonplace for search engines, polls, surveys, electronic commerce, and even on-line applications. Nearly all user interaction on the Web is through forms of some sort. This ubiquitous technology, however, is showing its age. It predates XML by half a decade, which is a contributing factor to some of its limitations:

• Poor integration with XML
• Limited features make even common tasks dependent on scripting
• Device dependent, running well only on desktop browsers
• Blending of purpose and presentation
• Limited accessibility features

A new technology, XForms, is under development within the W3C and aims to combine XML and forms. The design goals of XForms meet the shortcomings of HTML forms point for point:

• Excellent XML integration (including XML Schema)
• Provide commonly-requested features in a declarative way, including calculation and validation
• Device independent, yet still useful on desktop browsers
• Strong separation of purpose from presentation
• Universal accessibility

This updated article gives an introduction to XForms, based on the 21 August 2002 Working Draft, which is described as being a close precursor to a Candidate Recommendation draft.

Continue to XML.com and read the full article.

Web services are a set of tools that can be used in a number of ways. The three most common styles of use are RPC, SOA and REST.

Remote procedure calls

RPC Web services present a distributed function (or method) call interface that is familiar to many developers. Typically, the basic unit of RPC Web services is the WSDL operation.

The first Web services tools were focused on RPC, and as a result this style is widely deployed and supported. However, it is sometimes criticised for not being loosely coupled, because it was often implemented by mapping services directly to language-specific function or method calls… Many vendors felt this approach to be a dead end, and pushed for RPC to be disallowed in the WS-I Basic Profile.

Service-oriented architecture

Web services can also be used to implement an architecture according to Service-oriented architecture (SOA) concepts, where the basic unit of communication is a message, rather than an operation. This is often referred to as “message-oriented” services.

SOA Web services are supported by most major software vendors and industry analysts. Unlike RPC Web services, loose coupling is more likely, because the focus is on the “contract” that WSDL provides, rather than the underlying implementation details.

Representational state transfer

Finally, RESTful Web services attempt to emulate HTTP and similar protocols by constraining the interface to a set of well-known, standard operations (e.g., GET, PUT, DELETE). Here, the focus is on interacting with stateful resources, rather than messages or operations.

RESTful Web services can use WSDL to describe SOAP messaging over HTTP, which defines the operations, or can be implemented as an abstraction purely on top of SOAP (e.g., WS-Transfer).

Source: Wikipedia

In 1989 the Air Transport Association (ATA) adopted Computer Graphics Metafile (CGM) as the format for the interchange of 2-dimensional vector based technical illustrations in maintenance documentation. Both The Boeing Company and United Airlines, along with much of the rest of the industry, use CGM internally to transfer 2-dimensional vector data between diverse systems.

The decision to use CGM, both at the industry level and by individual companies, was made after a review of available open and proprietary formats. Requirements for creation, interchange, delivery, and use were considered. In addition, ATArequirements for intelligent graphics and the expansion of CGMto support application structuring played a major role in that decision.

Over the last few years with the explosion of the World Wide Web, delivery of technical documentation is migrating in that direction. Two emerging World Wide Web Consortium (W3C) vector graphic specifications have appeared to address requirements for scalable vector graphics on the Web. WebCGM was developed by the CGM Open Consortium and W3C graphics expertise as an application profile to the CGM standard based on the ATAgraphics interchange profile (GREXCHANGE). Scalable Vector Graphics (SVG)format was developed by a W3C working group and designed specifically for the Web environment.

This paper will review the requirements of the ATA(and companies like The Boeing Company and United Airlines) for graphics in technical documentation. The graphics formats available on the Web will be reviewed and compared against those requirements. In particular WebCGM and SVG will be examined in detail for delivery of technical illustrations in the Web environment. Based on this analysis, the authors will demonstrate why CGM and WebCGM will be the choice of the industry for interchange of 2-dimensional vector illustrations.

Source: GCA

This page is intended to provide an explanation of some of the features of the PNG format for non-technical users. As such, it doesn’t emphasize PNG features like freedom from patents; those are more of concern to developers. Where programmer information is given, it is principally to explain to the user why various applications may not perform as well as expected. Where performance claims are made–especially compression comparisons with other image formats–we assume that the PNG implementation is at least as good as the best freeware encoders. Note that this is currently not necessarily a valid assumption in the case of a number of popular (and expensive) image editors, but it’s not always clear where the problem lies.

Typical Usage of PNG

The Portable Network Graphics (PNG) format was designed to replace the older and simpler GIF format and, to some extent, the much more complex TIFF format. (See the main page or the history page for background information.) Here we’ll concentrate on two major uses: the World Wide Web (WWW) and image-editing.

For the Web, PNG really has three main advantages over GIF: alpha channels (variable transparency), gamma correction (cross-platform control of image brightness), and two-dimensional interlacing (a method of progressive display). PNG also compresses better than GIF in almost every case, but the difference is generally only around 5% to 25%, not a large enough factor to encourage folks to switch on that basis alone. One GIF feature that PNG does not try to reproduce is multiple-image support, especially animations; PNG was and is intended to be a single-image format only. (A very PNG-like extension format called MNG was finalized in mid-1999 and is beginning to be supported by various applications, but MNGs and PNGs will have different file extensions and different purposes.)

For image editing, either professional or otherwise, PNG provides a useful format for the storage of intermediate stages of editing. Since PNG’s compression is fully lossless–and since it supports up to 48-bit truecolor or 16-bit grayscale–saving, restoring and re-saving an image will not degrade its quality, unlike standard JPEG (even at its highest quality settings). And unlike TIFF, the PNG specification leaves no room for implementors to pick and choose what features they’ll support; the result is that a PNG image saved in one app is readable in any other PNG-supporting application. (Note that for transmission of finished truecolor images–especially photographic ones–JPEG is almost always a better choice. Although JPEG’s lossy compression can introduce visible artifacts, these can be minimized, and the savings in file size even at high quality levels is much better than is generally possible with a lossless format like PNG. And for black-and-white images, particularly of text or drawings, TIFF’s Group 4 fax compression or the JBIG format are often far better than 1-bit grayscale PNG.)

Like GIF and TIFF, PNG is a raster format, which is to say, it represents an image as a two-dimensional array of colored dots (pixels). PNG is explicitly not a vector format, i.e., one that can store shapes (lines, boxes, ellipses, etc.) and be scaled arbitrarily without any loss of quality (generally speaking). For that you probably want SVG or PostScript. (There are some private extensions to PNG that add vector information in addition to PNG’s regular pixels–Macromedia’s Fireworks does something along those lines–but no valid PNG may omit the pixel data.)

Read more good stuff on PNG on LibPNG

“Like any holy war, it’s hard to say for sure who might have won what, and there will be plenty of people who will never admit that the war is over, but my feeling is that, for now, my guys—the CSS2 zealots—have lost,” is the way the blog on philringnalda.com starts… Here the rest of the good post…

I don’t think there’s any question but what we won the first battle, over whether toolmakers should make it possible to use CSS2/XHTML (though there is still plenty of mop-up work to be done, convincing Ev. to do real paragraphs and <br /> among other things).

Once the war turned from may we to should you—should everyone be doing tableless layouts, should every weblog, should Scripting News—well, I think we’ve lost. We’ve demonstrated that you can do a weblog with CSS2 layout that looks fairly similar in all the latest browsers, and isn’t completely unreadable in older browsers, if you choose to use a layout that doesn’t require precise placement, or if you are willing to use hacks and hide your CSS from browsers that you know will mess it up. That’s nice, for fulltime working professional web designers, and even for some interested amateurs. For Jane Q. Blogger, working two jobs and only blogging after the kids are finally asleep, it seems a bit much. If we have to convince people that it’s a good thing to not do layouts that look the way they want them to, because to look that way they’ll need two stylesheets and four rules for every width they specify, we’ve lost.

Jane should be using a pure CSS2 template, the only sort provided by her blogging tool, you say? Well, take a look at our best cross-browser effort, the much linked to NN4+ template from saila.com. In my limited test suite (all Windows), in Netscape 4.79 the columns all start at different heights on the screen, and the right column isn’t actually resizing, it’s just sitting too far out to the right, being too narrow. When you shrink the window down enough, rather than horizontally scrolling, the columns overlap. To get any liquidity at all requires Javascript, since the page has to be redrawn after each resize. In Opera 6.0, everything behaves reasonably well, except for a gap at the right edge whenever the window is large enough. Internet Explorer 6 is quite well behaved until the window becomes small enough that the left and center columns collide. In Netscape 6.1, we see how the template is supposed to work, with the header filling the entire screen, and the columns never merging or overlapping. For a weblog aimed at Mozilla developers, that might be just fine, but I get more hits from Googlebot than I do from Netscape 6 and Mozilla combined. Although for my purposes it’s a step in the right direction (I’m looking for a NN4.x-safe template that will work with Blogger, where the lack of support for external stylesheets in the template switcher and on Blog*Spot means that @import is not an option), the need for incomprehensible IE5-specific conditional comments, the reliance on Javascript, and the general complexity make it an interesting demonstration, but not a workable solution.

We’re right: layout with stylesheets is cleaner, quicker, easier to maintain, you name it. It just isn’t practical in the real world of old browsers and people who want the layouts they want, not the layouts that CSS and its broken implementations are willing to allow. Sadly, even the vaunted NYPL Style Guide agrees:

Source : http://weblog.philringnalda.com/2002/02/25/the-css2-wars-i-think-we-lost

CC/PP stands for Composite Capabilities/Preferences Profile, and is a system for expressing device capabilities and user preferences. With CC/PP, a user with a specific preference, or disability-related need can clarify that even though their browser handles millions of colours, they personally can only distinguish certain colours. Or, perhaps the user navigates exclusively with a keyboard or stylus.

Why do we need CC/PP?

With the growing popularity of ubiquitous Web devices spread across such a broad range of media and bandwidth, authoring for the Web can sometimes look like a very difficult equation to solve: how can a Web author provide cool multimedia Web content, while keeping that content small and simple enough for very basic devices?

Managing multiple devices is not a new problem, and even though the rapid growth of Web appliances beyond the familiar Web browser makes the challenge especially acute, a few solutions have been developed over the years.

Most of these solutions are based on content selection: the content is given in several equivalent variants, or has mechanisms to define alternative behaviour. Then, at the time the resource is served, either the server chooses which variant is most suitable, or the user agent decides what to do with the choices it is given.

This is easily achieved because user agents identify themselves to servers and scripting languages, and through specific features included in Web document languages:

• Server-driven content negotiation, as defined by HTTP,
• On-the-fly content selection and presentation based on user agent detection, using scripting languages,
• HTML object and link elements have mechanisms defining alternate behaviours,
• SMIL (pronounced “smile”), the multimedia language for audio/visual content, has a switch element defining alternate elements to chose from, and can be used, for example, to choose some content based on available bandwidth,
• CSS also has such a mechanism called Media Queries for selecting appropriate style sheets.

Read more on the shortcomings of current methods on Web Standards

Work is currently going on to extend web style sheets to include facilities for the visually impaired as part of the HTML work within the World Wide Web Consortium (W3C) based at the Massachusetts Institute of Technology in the USA and INRIA.

HTML was originally intended as a structural markup language (defining, for instance what the top-level heading is for a document, but not how it should be displayed), but later additions by, amongst others Netscape and Microsoft, added new markup to HTML that was only there to influence the presentation, for example <BLINK>.

The Style Sheets work brings HTML back to the original aim, while still allowing authors to influence the presentation. The first specification of Style Sheets for HTML, CSS1, is currently a working draft within the W3C process, and it allows authors in a fairly simple manner to influence aspects such as font, colour, margins and so on.

One advantage of HTML being a structure language over a presentational language, is that it is consequently relatively easy to make an Aural Browser using a speech synthesiser, that just reads a document to you. The advantage, for instance, of using <EM> to specify emphasis, rather than <I> to create italic text, is that such an aural browser can read the emphasised text with more emphasis. This is clearly of advantage to all people who are functionally blind. While this of course includes visually impaired people, it can also include, for instance, people driving, or people involved in other eye-busy tasks.

Work is currently going on to extend CSS to include speech and other aural properties. For instance it might be possible to specify that headings come from the left of the audio field, and body text from the centre, or alternatively, that headings get read in a deeper, or louder voice, or both. This work was initiated by T.V. Raman of Adobe Systems, who is himself blind, and whose PhD. thesis was on the subject of voice synthesis and automatic reading of LaTeX documents. He surfs the web using the Emacs W3 web browser hooked up to a speech-synthesiser that implements an early version of the specification that is currently being worked on. T.V. Raman’s web page with demos:
http://www.cs.cornell.edu/Info/People/raman/

For more information:
http://www.w3.org/Pub/WWW/Style

Repost from: http://www.ercim.org/publication/Ercim_News/enw28/lie.html