Welcome To BlogerDesign

The ability to control the flow of your program, letting it make decisions on what code to execute, is valuable to the programmer. The if statement allows you to control if a program enters a section of code or not based on whether a given condition is true or false. One of the important functions of the if statement is that it allows the program to select an action based upon the user's input. For example, by using an if statement to check a user entered password, your program can decide whether a user is allowed access to the program.


Without a conditional statement such as the if statement, programs would run almost the exact same way every time. If statements allow the flow of the program to be changed, and so they allow algorithms and more interesting code.

Before discussing the actual structure of the if statement, let us examine the meaning of TRUE and FALSE in computer terminology. A true statement is one that evaluates to a nonzero number. A false statement evaluates to zero. When you perform comparison with the relational operators, the operator will return 1 if the comparison is true, or 0 if the comparison is false. For example, the check 0 == 2 evaluates to 0. The check 2 == 2 evaluates to a 1. If this confuses you, try to use a cout statement to output the result of those various comparisons (for example cout<< ( 2 == 1 );)

When programming, the aim of the program will often require the checking of one value stored by a variable against another value to determine whether one is larger, smaller, or equal to the other.

There are a number of operators that allow these checks.

Here are the relational operators, as they are known, along with examples:

>     greater than              5 > 4 is TRUE
<     less than                 4 < 5 is TRUE
>=    greater than or equal     4 >= 4 is TRUE
<=    less than or equal        3 <= 4 is TRUE
==    equal to                  5 == 5 is TRUE
!=    not equal to              5 != 4 is TRUE

if ( TRUE )
 Execute the next statement

if ( TRUE ) {
 Execute all statements inside the braces
}

if ( TRUE ) {
 // Execute these statements if TRUE
}
else {
 // Execute these statements if FALSE
}

#include  

using namespace std;
  
int main()                            // Most important part of the program!
{
 int age;                            // Need a variable...

 cout<<"Please input your age: ";    // Asks for age
 cin>> age;                          // The input is put in age
 cin.ignore();                       // Throw away enter
 if ( age < 100 ) {                  // If the age is less than 100
    cout<<"You are pretty young!\n"; // Just to show you it works...
 }
 else if ( age == 100 ) {            // I use else just to show an example
    cout<<"You are old\n";           // Just to show you it works...
 }
 else {
   cout<<"You are really old\n";     // Executed if no other statement is
 }
 cin.get();
}

A. !( 1 || 0 )         ANSWER: 0 
B. !( 1 || 1 && 0 )    ANSWER: 0 (AND is evaluated before OR)
C. !( ( 1 || 0 ) && 0 )  ANSWER: 1 (Parenthesis are useful)

Getting set up

#include 



using namespace std;



int main()

{

cout<<"HEY, you, I'm alive! Oh, and Hello World!\n";  cin.get(); } 

int x;

int a, b, c, d;

char letter;

float the_float;

#include 



using namespace std;



int main()

{

int thisisanumber;



cout<<"Please enter a number: ";  cin>> thisisanumber;

cin.ignore();

cout<<"You entered: "<<>

a = 4 * 6; // (Note use of comments and of semicolon) a is 24

a = a + 5; // a equals the original value of a with five added to it

a == 5     // Does NOT assign five to a. Rather, it checks to see if a equals 5.

a <> 5  // Checks to see if a is greater than five

a == 5 // Checks to see if a equals five, for good measure

This tutorial uses Photoshop CS2 however it is also suitable for PSCS and PS7 users.

Using a basic circle, this tutorial will demonstrate some of the effects that the Layer Style options is used to create.

This tutorial is large(36 pages) and is available in PDF Format. DOWNLOAD BY CLICKING HERE

You can download Adobe Acrobat Reader for free if required from www.adobe.com




ReadMore...

This tutorial will help you create a basic round glass ornament, just in time for the holidays.

1. Begin by creating a new image in the dimensions you want. Be sure to click Raster Background and Transparent.


2. Activate the Ellipse Tool (Q) and choose a background color you want your ornament to be. Draw a vector circle and center it vertically on your layout using the Object Selection Tool (O).

3. Duplicate the vector circle onto a new layer by right-clicking on the layer containing the circle and choosing Duplicate.

4. Expand the layer containing the duplicated circle by clicking the plus sign located on the left side of the layer.

5. You should now see the sub-layer containing the vector circle.

6. Double-click the sub-layer containing the duplicated circle (be sure you click the sub-layer and not the Vector layer). Once you double-click the sub-layer containing the circle, you should see the following window:

7. Click the fill block on the bottom and choose the Gradient tab. Choose the black-white gradient. Enter 180 for the Angle, Repeats = 0, check Invert, Linear style. Click OK.

8. The duplicated circle should now have changed to the black-white gradient.

9. Change the blend mode for the black-white gradient to Hard Light (try experimenting with different blend modes for various looks).

10. Your ornament should now look like this:

11. Let’s give the ornament a shinier glass look. Create a selection by activating the Object Selection tool (O) and Ctrl+Shift+B. Your circle should now have marching ants surrounding it.

12. Create a new Raster layer (Layers > New Raster Layer > OK).
13. Expand the selection by clicking Selections > Modify > Expand. Expand the selection by 2 pixels. Click OK. The marching ants should now be on the outside of your circle.

14. Create a shiny glass look by clicking on Effects > Artistic Effects > Balls and Bubbles. On the Shape tab, choose the Single ball or bubble and check Maximum possible size.

15. Click the Illumination tab and fill in with the following settings:

16. Click OK. Change the blend mode for this layer to Overlay. You should now have a shinier surface on your ornament.

17. Click on the layer containing your original circle. Then using the Magic Wand tool, click on the outside of the circle, selecting the area surrounding the circle.

18. Click the layer containing the glassy bubble and hit the delete key on your keyboard. Merge visible layers (Layers > Merge > Merge Visible).

19. At this point, you could save the image as a PNG file and use it as is. Or, you can create the metal hanging cap.
20. Choose the Rectangle tool (G). For the background color, choose the Metal steel gradient, linear style, angle = 90, check Invert. Click OK.

21. Draw a small rectangle at the top of the ornament and center it vertically using the Object Selection tool (O).

22. Convert the rectangle into a raster (Layers > Convert to Raster Layer). Apply an inner bevel with the following settings and click OK.

23. Your ornament should now have a metallic cap on top.

24. Create a hanging loop by using the Ellipse tool (Q) and drawing a thin ellipse using the same Metal steel gradient as your stroke color. Move the layer containing the loop below the cap so that it sits behind the cap.

25. Apply an inner bevel to the loop and click OK.

26. Merge all visible layers and save as a PNG file. Your ornament is now ready for “hanging!”

Most, if not all of the permanent topics of conversation on XML-DEV revolve around two camps of people: one which thinks aspect N of XML is a wart, the other which thinks N is an elegance. These threads never end because, in part, there is no final or absolute context within which XML is meant to be used. Whether you think of N as a wart or an elegance is context dependent and interest relative. It depends almost entirely on who you are and what you want and need XML to do. In other words, all opinions about XML are equal. Except that that's not really true. All opinions about XML are equal, except some are more equal than others. Among the more equal opinions are ones held by the people who drafted the XML specification.

Among that select group of people, as far as XML-DEV is concerned, Tim Bray stands out, if for no other reason than he has consistently contributed to the conversational life of the community. So when Bray, over the course of a few weeks, leads an effort to relocate XML-DEV and publishes a widely-read essay in which he seems to question XML itself, it's time to take a closer look.

Is XML Too Hard?

In a recent weblog entry, one which has been picked up by Slashdot, Bray asks whether XML has become too hard for programmers. Faced with writing code "to process arbitrary incoming XML", Bray confesses that the experience was "irritating, time-consuming, and error-prone" -- quite an admission from someone as instrumental in the creation of XML as Bray. The point here -- before someone accuses me of hero worship -- isn't that Tim Bray is always right. He isn't. The point is that when Tim Bray starts talking about XML's problems, it makes sense for the XML development community to pay some attention.

So what's Bray's beef? It isn't, he says, that XML parsers are so hard to write. If they were, Bray says, there wouldn't be so many of them (which doesn't strictly follow, logically speaking, but it may be a useful heuristic). The problem is that XML parsers are so hard to use. (I wrote about a similar issue -- the difficulty of SAX or DOM for some kinds of programmer -- in one of my first XML-Deviant columns, "DOM and SAX Are Dead, Long Live DOM and SAX".)

Specifically, Bray offers the standard lament: DOM processing is inefficient, SAX processing is awkward.

If I use any of the perl+XML machinery, it wants me either to let it read the whole thing and build a structure in memory, or go to a callback interface.

Since we're typically reading very large datasets, and typically looking at the vast majority of it, preloading it into a data structure would be impractical not to say stupid. Thus we'd be forced to use parser callbacks of one kind or another, which is sufficiently non-idiomatic and awkward that I'd rather just live in regexp-land.

What? Bray "parses" XML with regular expressions? Apparently so, at least for some data munging tasks at Antartica, his data-mapping company. He's even written some code to make regexing XML more reliable:

Now here's the dirty secret; most of it is machine-generated XML, and in most cases, I use the perl regexp engine to read and process it. I've even gone to the length of writing a prefilter to glue together tags that got split across multiple lines, just so I could do the regexp trick.

Bray's preferred way of parsing XML for some kinds of project, like his weblog software, would be to have a kind of regular expression syntax which "abstracts away all the XML syntax weirdness, ignoring line-breaks, attribute orders, choice of quotemarkers and so on". While his example is Perl, it's not Perl-specific. "I want to have my idiomatic regexp cake," Bray says, "and eat my well-formed XML goodness too".

XML-DEV reacted to Bray's essay in a relatively muted way, perhaps because it was busy discussing his proposal to relocate XML-DEV? Simon St. Laurent suggested that Bray's lament reflects the different expectations and assumptions which follow from the markup and programming worlds. Dare Obasanjo took Bray to task, suggesting that what Bray is asking for is already available in Java and C# (and, as Daniel Veillard pointed out, in libxml2 and so in any language, like Python, which has libxml2 bindings; likewise, Sean McGrath reminded XML-DEV that this processing style is available in his Pyxie Python toolkit), namely, a "pull-based XML parser". Obasanjo went even further:

Tim's post indicates that he is quite disconnected from the world of modern XML programming practices, I especially like his "The notion that there is an 'XML data model' is silly and unsupported by real-world evidence" quote. I'm interested in what criteria he used to determine that the thousands of users of XPath, XSLT and the DOM don't count as "real-world evidence".

Micah Dubinko takes a different approach, noting that part of the difficulty of parsing some kinds of XML is handling ID values. One of the changes that might be made to XML to make it less painful to process is to fix the ID issue. As Dubinko puts it,

Anyone who's worked much with XML knows that IDs are painful, since they require DTD or schema processing. A recurring proposal has been circulating for a self-describing xml:id attribute that confers ID-ness without need of DTD or schema. With that in place, even XML delivered inside the DTD-free zone of a SOAP envelope could be handled with code not significantly more complex than Adam's example, and without the dependencies and hassle of a schema language.

Two very substantial posts, by Robin Berjon and Barrie Slaymaker, responded specifically to Perl-specific part of Bray's comments. Berjon makes the obvious point:

A couple years after you think you and your friends have convinced all the Perl community to not use regex based parsers on XML you get Tim Bray to hit you on the back of the head with one. I guess it's fair though, because he makes sense.

Which is especially telling (and rather funny) if you remember classics which asked whether "wily Perl hackers" could handle XML. Berjon's primary suggestion is to commend Barrie Slaymaker's XML::Filter::Dispatcher module:

It is basically a collection of utilities wrapped inside rules that match an XML stream using an XPath-like language (which is probably preferable to raw regexen, and has in fact similar functionality). They will do things such as maintain state for you or assist you doing so, in a way that is much simpler than SAX. You need to learn a new little language, but if you know XPath it's a five minute job. I don't think the docs do it full justice.

This sounds an awful lot like the kind of thing Bray is asking for.

If you're a Perl-XML hacker, you could do far worse than paying very close attention to Barrie Slaymaker's post about XML::Filter::Dispatcher and XML::Essex. I can only quote some of its highpoints here, but it definitely deserves a careful reading.

XML::Essex is "a prototype of a pull mode scripting environment ... that is also event driven so it allows while ( pull ) style processing without reading the entire document (via Perl's newish ithreads)". That is, it is meant to allow Perl programmers to deal with XML files in much the same way as they'd deal with other text files. It is, Slaymaker says, "an attempt to build a toolkit that allows processing XML files in the same way that you would process a text file, modulo the fact that text files are treated as flat sequences of records in Perl while XML is hierarchical". Again, if you're interested in Bray's lament specifically for its Perl-angle, you should take a careful look at Barrie Slaymaker's recent work.

The previous three editions of XML-Deviant reviewed Web Forms 2.0, or WF2, a Member Submission made to the W3C by a loose group called The Web Hypertext Application Technology Working Group, often abbreviated WHATWG.

This week, continuing a web application theme leading up to the XTech Conference, XML-Deviant takes a look at the issues involving the broader internet application community. The first stop is the W3C Team Comment on WF2. Normally, the W3C won't acknowledge a Member Submission if it falls under the domain of an existing Working Group--in that case the submission should be made directly to the Working Group in question. As the lead-in quote shows, though, the submission was acknowledged. Additionally, the Team Comments offered a few specific suggestions:

1. Consider separating the backwards-compatible features from the features that require users to update their user agents or rely on scripting.

2. Provide comprehensive use cases and requirements for each enhancement.

3. Demonstrate how Web Forms 2.0 maps to XForms (and the reverse), giving more attention to the features in Web Forms 2.0 that are similar to XForms.

4. Participate in the development of XHTML and XForms specifications (note that Opera has been a member of the HTML Working Group for 4 years.)

5. Build a community, with cooperation from the W3C, to discuss, develop and promote adoption of improved forms on the Web.

While a good starting point, these comments by nature are addressed only to the WHATWG. That group didn't form in a vacuum; it formed as a response to pre-existing conditions in the community. Accordingly, any one-sided plan for change is simply doomed. On the other hand, the group is specifically asking for comments, so nobody should be surprised if some of the comments point to WF2. Even then, however, it's worth thinking about the wider implications of suggested changes. So with that, the remainder of this column offers some specific points for discussion and alignment within the community.

Point: Where the state goes. Earlier, this column's review of WF2 introduced FormAttic, a simple framework for client-side forms validation, in order to highlight an important discussion about the design of forms languages: namely, that new features require new information to be specified somewhere in a target document. FormAttic placed all the additional information in one place, in the document head. WF2 places the information across many elements throughout the document. Lots of ink could be spilled over discussions about which way is better.

But the interesting thing is that the existing XForms specification already caters to both ways. A fully specified XForms Model appears in one place in the document head, but for cases when that is too heavyweight, a technique called (with tongue firmly in cheek) lazy author style allows the scattered form control elements themselves to contain all the needed information. XForms and WF2 are more closely related than has been credited. Without serious changes to either specification, they could be even more so.

Point: Common foundation. The XForms Model, which is in turn based on the XPath data model and the XML Infoset, provides a common dictionary of terms for specifications and implementers to use. Note that this doesn't automatically imply the need to use XPath itself, only the data model, which in practical terms only means writing specifications a certain way and using certain terminology. The result will be that developers familiar with WF2 will have an immediate familiarity with XForms, and vice versa. Additional areas of overlap, especially around serialization and submission handling, can also be more easily identified this way. Many of the improvements found in areas of WF2 fit in with current work on the XForms 1.1 Working Draft.

Point: Common framework. WF2 is defined in terms of Modularization of XHTML, a framework for mixing and matching different parts of XML vocabularies. Without using a separate heavyweight specification, XForms uses another layer on top of XHTML Modularization to mix and match form-specific components. The result is diagrams like this puzzle piece, which as far back as 2001 already showed XHTML as an option for user interface. It should be possible to use the updated UI controls defined in WF2 with the rest of the XForms core, not to mention other kinds of combinations.

Point: Discard the WF2 repeat model in favor of the existing one. Previously I wrote about the WF2 repeat model, which has some shortcomings besides being duplicative. The WF2 submission itself acknowledges: "There is some debate about whether the repetition model section should be included or not."

Point: Acknowledge the need for a transition. This might be the hardest point for both respective sides to come to terms with, yet in some respects it's the easiest since it involves only editing one's viewpoint as opposed to editing a specification or working code. Perhaps Gerald Weinberg's Second Law of Consulting sums it up best: "No matter how it looks at first, it's always a people problem."

The huge quantity of existing code, markup, practice, and W3C Recommendations speaks for itself. So does the demand for more advanced solutions. There are valid 'before' and 'after' states in this discussion, which points to the need for a bridge between the two.

Another area of common ground comes from scripting, which any kind of client-side transition plan will involve. Work like FormFaces or DENG feel eerily similar to the kind of preliminary work going into WF2, such as that from the remarkable Dean Edwards. It doesn't take a big imaginative leap to visualize these kinds of projects coming together.

Point: Unify the community. One community working out these issues will be better than two or n, even though compromises will need to happen. The W3C might often get criticized for producing cumbersome "design-by-committee" specifications, but it still holds a leadership role in web applications standards space. If that weren't the case, the WHATWG wouldn't have made a Member Submission out of WF2 in the first place. The proprietary forms market is fractious enough. Let's not have the standards-based forms sector be the same way.

Conclusion

In preparing this article, I was stuck by how many areas of common ground exist between XForms and WF2, much more so than reading either specification alone would indicate. Still, not enough work has gone into identifying and expanding these areas. This is where XML-Deviant readers can help. In the comments section below or in your weblog, post some constructive comments, markup samples, or other ideas on how to move this community forward. A later issue of XML-Deviant will report on the progress.

Births, Deaths, and Marriages

OpenReader announcement: Open-standards eBook Format and Reading System

New discussion groups for Open-standards eBook Format development as well as a reference implementation.

Documents and Data

Uche Ogbuji's latest article, Principles of XML Design: When the Order of XML Elements Matters, which spawned a useful thread on xml-dev this week.

How to implement Google Maps (and other Ajax patterns) with XForms.

For more information on Gerald Weinberg's Laws of Consulting, see The Secrets of Consulting.

Chapter 5: Managing Spam

Most people consider spam to be any unsolicited e-mail that they might receive that attempts to sell them something¹. It can also include e-mails with chain letters, political statements, or messages from people who just need some attention. Although some people might think that the e-mail version of spam was named after the food SPAM,² because both are considered tasteless and a waste of time (at least to some people), nothing could be further from the truth. (As an aside, SPAM is served during breakfast at McDonald's in Hawaii, where it has the highest consumption rate per capita in the United States.²)

The origin of the use of the term spam for unsolicited e-mail appears to come from the Monty Python skit about SPAM³. The Vikings in the skit annoyed a waitress by repeating the word spam over and over again. In much the same way, unsolicited e-mail can elicit the feeling of annoyance in people who receive it. The way in which the Monty Python skit was connected to the act of unsolicited communication came from the Multi-User Dungeon (MUD)⁴ community. One member of that community, after becoming upset with his treatment by some of the other members, created a macro to repeat the word spam several times in the MUD environment during a sacred hatching. Later on, MUD members would refer to the event as the time they got "spammed."

SoftQuad's XMetaL takes a good first cut at a workable interface for writers (as opposed to programmers or data-entry clerks) working with structured text. It's more than an "XML editor", a label that might be applied to products like XED, XML Spy, and Vervet that provide basic data and metadata editing functions with explicit control over XML markup. XMetaL falls into new category that you might call XML or structured word processing along with Arbortext's Adept Editor and Word Perfect SGML.

	XMetaL is available for Windows platforms at $495 per user.
Find out more about XMetaL in our product guide. Have you used XMetaL? Share your opinion with us.

XMetaL is relatively inexpensive, relatively easy to set up, and relatively easy to use as a word processing tool for writers who need to produce valid documents according to established formulas. The target market for SoftQuad's XMetaL includes the traditional market for SGML editors, tech doc and integrated vertical applications. However, it should make it easier to deploy a structured editor to an off-site writer who may have little or no training in XML. Another target is editorial groups in which Microsoft Word is producing copy that will eventually be converted to XML and will need to stand up to XML validation. This includes Web sites such as the Wall Street Journal Interactive Edition, where writers use a customized version of Word to produce RTF files that are converted to XML, validated, and then fed into the production system or sent back to the author for revision.

So the goal for XMetaL was to be a word processing tool for structured documents that is as easy to use as Word when customized for an individual DTD. SoftQuad, Adobe and Arbortext all have experience customizing an interface for a specific environment. Most of the successful, SGML-authoring projects utilize a dedicated editor that conforms to its document type and work requirements. In XMetaL, SoftQuad has tried to produce a tool that can be set up in two weeks by anyone with general scripting skills instead of two months by an XML consultant.

Eric van der Vlist is the author of XML Schema.Microsoft Office Embraces XMLFor many participants, the most memorable event of XML 2002 will be JeanPaoli’s presentation of Office 11, which promises to deliver easier access toXML for hundreds of millions of workstations.Those of us who had to connect a Windows PC to the Internet in theearly 90s remember the difficulty of choosing and installing TCP/IP andthe browser software necessary to access and browse the Web. At that time,Microsoft didn’t be

Microsoft Office Embraces XML

For many participants, the most memorable event of XML 2002 will be Jean Paoli's presentation of Office 11, which promises to deliver easier access to XML for hundreds of millions of workstations.

Those of us who had to connect a Windows PC to the Internet in the early 90s remember the difficulty of choosing and installing TCP/IP and the browser software necessary to access and browse the Web. At that time, Microsoft didn't believe in the future of the Internet, TCP/IP wasn't natively supported by Windows, Internet Explorer was a vague project in a laboratory, and many companies had developed market segments left uncovered by Microsoft.

This era was wiped away by a U-turn, which I have always considered a miracle from a company of the size of Microsoft. Within months, it bundled a TCP/IP stack and Internet Explorer with Windows. Internet features have been rapidly added to Office. Users applauded. Companies positioned on these segments either changed their strategy or disappeared, which is believed to have decreased the overall possibility for innovation in some domains.

The impression given in the presentation by Jean Paoli, co-editor of the XML 1.0 recommendation and pilot of the "XMLization" of Office, is that Microsoft is doing with XML what it did with the Internet.

XML was already well-supported by Microsoft BackOffice products from Biztalk to CMS through XML Server, but a key piece was missing: tools to let users manipulate XML on their workstations. The issue of editing XML documents is still as difficult as the connection to the Internet in the early 90s: technically there is a solution and many XML editors are available, but the financial, institutional, and human impact of deploying these tools on a large scale is considered a major obstacle by many organizations.

"XML for the masses" is the target of Office 11, and Paoli's presentation suggested that Microsoft will likely meet the target. Without major innovations (except maybe the linking of XML documents to Excel spreadsheets using XPointer references), Office 11 appears to xmlizing Office using largely standard technologies and enabling the manipulation of arbitrary XML documents using customer-chosen schemas:

• Word 11 has been transformed into a XML editor and can be used to edit any XML document, assuming you can write a W3C XML Schema for it. The presentation can be configured and validation is done on the fly like spell-checking. A standard XML format has also been added for ordinary Word documents.

• Excel XP already exports documents as XML. Excel 11 adds support for arbitrary documents and, maybe more interesting, the possibility to import values from XML documents as with a DBMS. The selection of the values to import is done through drag and drop; the links are stored as XPointer expressions.

• XDocs is a new application that defines and uses document-oriented forms, more similar to the forms in Lotus Notes than those on the Web. User input may be stored together with the form in a XML document using a schema defined by Microsoft or in external XML documents with arbitrary schemas.

• Access 11 can export its content as XML using a user-supplied schema.

• Visio has its own XML format and can also read arbitrary XML documents and display their content in its drawings. Visio is the first Microsoft application to support SVG; it can load and save SVG documents.

• Front Page 11 includes a WYSIWYG XSLT editor to define XSLT transformations through drag and drop.

Powerpoint is the only piece without an XML update because, according to Paoli, of the lack of time. For the rest of the applications, XML can be used as a channel of information between front and back office applications, but also between front office applications, creating a lot of new possibilities for users, consultants, and integrators who will be able to exploit them.

"XML for the masses", the target of Microsoft, is not the same as the target of the XML editors we know today, and it will probably take some time for Word to become a serious challenger. Nevertheless, many will be tempted to use a tool which is installed on so many workstations. The effect of this may well be to reduce the opportunity for competition, innovation, and value-add in the existing XML editor world, yet also to create new market segments.

Often criticized for its "embrace and extend" strategy, Microsoft has finally decided to continue to play the game with XML, even though the extensibility of XML opens new and unpredictable possibilities. But Microsoft needs to control all the major market segments in fear that XML might give to the masses the possibility of emancipation from its domination.

While the deployment of XML on millions of workstations is good news in the short term, it will certainly modify the landscape of desktop XML. The shape of this new landscape, and the longer-term consequences, are difficult to foresee.

OpenOffice: the XML format for the masses

Jean Paoli for Microsoft and Daniel Vogelheim for OpenOffice both chose the same title "XML for the masses" for their presentations, a commonality which hides two very different approaches from the editors of two competing office productivity suites.

The strategy of OpenOffice is to focus on the XML format natively used to store the documents. In his presentation Daniel Vogelheim gave an overview of the OpenOffice XML format and justified the design decisions taken to meet the following requirements:

• use existing standards -- don't reinvent the wheel
• "transformability" -- the format must be usable outside of the office application
• first class XML -- all structured content must be accessible through XML structures

The result is a complex format (over 450 elements and more than 1600 attributes), with a good amount of redundancy, but easily readable and easily transformable. To some extent it's an XML format for users more than for developers.

This format has been given as an input to the OpenOffice OASIS Technical Committee, which aims to create an "open, XML-based file format specification for office applications."

For Microsoft, the strategy appears to be to bring XML tools to each desktop, and leave each user free to choose appropriate schemas, rather than promoting an XML office format which will be specific to Microsoft, and for which a licensing model is still unclear.

If the target of Microsoft Office 11 is to deliver XML tools to the masses, the target of OpenOffice is to become the XML office format for the masses.

ISO DSDL on the move

Document Schema Definition Languages (DSDL) is a project of the ISO/IEC JTC 1/SC34/WG1 working group chaired by Charles Goldfarb. After the meetings held in Baltimore during XML 2002, this working group has published a set of recommendations which have been all approved:

• Relax NG specification is published as "ISO/IEC FDIS 19757-2, DSDL Part 2: Regular-grammar-based validation - RELAX-NG". This stage is similar to a W3C Proposed Recommendation and the specification should be approved as a final ISO standard within a period of two months.
• Part 0 (Overview) is published as a CD (i.e. a first Working Draft).
• Part 4 (Selection of Validation Candidates) is published as a CD. Proposed by Murata Makoto, this part defines a language for selecting XML islands which can be validated through different schemas. The document is derived from prior work known as "Relax Namespaces".

DSDL has also advanced the definition of the remaining parts, and several of them should lead to publications during the next meeting at XML Europe 2003. Among the decisions taken on part 1 (Interoperability Framework), are as follows:

• The Interoperability Framework should allow one to use existing languages without modifications and thus to manipulate full documents instead of fragments. This approach will follow the principles of the Schemachine proposal by Rick Jelliffe, but it will be made more declarative and less procedural.

• My own XVIF proposal is considered interesting and an extension mechanism will be added to Relax NG to support it in a more standard way.

Further reading on DSDL and XVIF:

• Updated release of XVIF
• RELAX NG becomes ISO draft standard

A burst of schemas

For different reasons many XML 2002 presentations proposed the use of multiple validations and transformations for advanced needs, rather than using a single schema considered too complex or even impossible to write and maintain.

Perhaps influenced by my editorship of "DSDL part 1 -- Interoperability Framework", I observed the justification of such a framework returning as a leitmotif in many presentations:

• Liora Alschuler, in her presentation " Layered Constraints: The Proposal for HL7 Healthcare Templates," explained why, in face of the huge diversity of the practices for health reports, HL7 has chosen to associate a very lax generic schema together with templates, i.e. specific constraints which formalize the different local usages of the common schema.

• Walter Hamscher in " XBRL: XML, XLink, and the Revolution in Corporate Reporting" explained why, for similar reasons, XBRL has chosen to express most of the structure of its reports as extended XLink link bases. Since these links cannot be validated using W3C XML Schema, to be complete the validation of XBRL documents requires a validation by the application layer that could also be performed using a language such as Schematron.

• Gabe Beged-Dov in " Normalized Metadata Format: RDF Meets XML Schema" showed how RDF documents may be "normalized" to facilitate their validation through W3C XML Schema.

• Eric Freese in " Using DAML+OIL as a Constraint Language for Topic Maps" proposed a modification of the syntax of XTM Topic Maps documents (which could be done by a XSLT transformation) that enables their validation using RDF applications such as OWL or DAML+OIL.

• Bob DuCharme in " Maintaining Schemas for Pipelined Stages" has shown that the customization of generic W3C XML Schema or Relax NG schemas with added metadata could be performed through XSLT transformations more easily than using the derivation techniques of these languages.

There are few commonalities between these presentations, but all of them show how, confronted with the issue of a complex validation in very different domains, projects have chosen to split the validation of their documents into different, easier to write, elementary steps.

That's also the approach taken by DSDL, the reason why it will be a multi-part standard, and the justification of its part 1, Interoperability Framework, which will define a language to describe the choreography of the elementary steps needed to perform a complex validation.

Impossible, Except For James Clark

The fact that the translation of Relax NG schemas into W3C XML Schema was considered impossible wasn't a good enough reason for James Clark, who presented at XML 2002 the latest progress of Trang, his multi-format schema converter.

While it is not possible to transform any Relax NG schema into W3C XML Schema, Clark considered that in most of the cases a converter smart enough to figure out the intent of the author should be able to write a readable W3C XML schema. This would be as good as a schema written directly using W3C XML Schema and a good approximation of the Relax NG original schema. Clark's presentation showed that this goal is not far from being met.

To achieve his aim, Clark had to make abstraction of the syntaxes beyond the two schema languages and to define a data model which is intermediate between Relax NG and W3C XML Schema. The translation is done in two steps: the Relax NG schema is parsed and feeds the data model, and criteria are applied to this data model to decide which W3C XML Schema should be used to get the best results both in term of approximation and readability.

The results from the examples presented by Clark is outstanding, and he has acknowledged that writing Trang was much more complex than writing a Relax NG implementation.

There appears to be quite a demand behind this tool too, as many developers are attracted by the simplicity of Relax NG, while they need to publish WXS schemas to be used by an increasing number of tools (Office 11 will require WXS schemas). Clark's answer to this request is simple: "don't bother with W3C XML Schema, write your schemas with Relax NG and use Trang to convert them."

Literate Programming in XML

Norm Walsh presented at XML 2002 his implementation ( XWEB) of Literate Programming in XML, available as part of his DocBook stylesheets, which enables the extraction of both documentation and code from common documents.

Introduced in 1984 by the father of TeX, Donald Knuth, Literate Programming is a software development methodology that focuses on documentation by embedding the source code in the documentation. Michael Sperberg-McQueen has proposed its application to SGML back in 1993.

Its principle is to document code fragments (classes, methods, variables or XSLT templates are examples of code fragments), to include the code fragments in their documentation, and to link them into a "web". This web can then be transformed to produce, on one hand, readable documentation in any format and, on the other, the source code.

The XML implementation presented by Walsh is thus based on mature concepts, and its current version was published in March 2002. It supports not only embedding traditional languages such as Perl or Java but also XML languages such as XSLT, schemas, or any other XML "code". Support for languages such as Python would probably require some adaptation since XWEB doesn't appear to care much about indentation.

Literate Programming isn't incompatible with other methodologies such as Extreme Programming; among the extensions which seem most interesting, one could probably easily add the definition of the unit tests within the documentation of the code fragments.

Purists will also note that, following tradition, XWEB is implemented through XWEB documents, a minimal XSLT transformation being provided to "bootstrap" these documents into usable pieces of code, which consist mostly of XSLT transformations.