The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

NEWS
Cover Stories
Articles & Papers
Press Releases

CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG

TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps

EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Last modified: September 02, 2008
XML Daily Newslink. Tuesday, 02 September 2008

A Cover Pages Publication http://xml.coverpages.org/
Provided by OASIS and Sponsor Members
Edited by Robin Cover


This issue of XML Daily Newslink is sponsored by:
Primeton http://www.primeton.com



W3C Working Draft for the Web IDL Specification
Cameron McCormack (ed), W3C Technical Report

W3C announced the publication of a Working Draft for the "Web IDL" Specification, produced by the W3C Web Applications Working Group, part of the Rich Web Clients Activity in the W3C Interaction Domain. The document was edited by Cameron McCormack, W3C Invited Expert. "Web IDL" defines an interface definition language that can be used to describe interfaces that are intended to be implemented in web browsers. Technical reports published by the W3C that include programming language interfaces have typically been described using the Object Management Group's Interface Definition Language (IDL). The IDL provides a means to describe these interfaces in a language independent manner. Usually, additional language binding appendices are included in such documents which detail how the interfaces described with the IDL correspond to constructs in the given language. However, the bindings in these specifications for the language most commonly used on the web, ECMAScript, are consistently specified with low enough precision as to result in interoperability issues. In addition, each specification must describe the same basic information, such as DOM interfaces described in IDL corresponding to properties on the ECMAScript global object, or the unsigned long IDL type mapping to the Number type in ECMAScript. This "Web IDL" specification defines a syntactic subset of OMG IDL version 3.0 for use by specifications that define interfaces. A number of extensions are given to the IDL to support common functionality that previously must have been written in prose. In addition, precise language bindings for ECMAScript Third Edition and Java are given. Previous working drafts of this document were called "Language Bindings for DOM Specifications." Changes made to this document can be found in the W3C public CVS server.

See also: the W3C Web Applications (WebApps) Working Group


IETF Common Intrusion Detection Signatures Standard
Adam Wierzbicki, Jacek Kalinski, Tomasz Kruszona (eds), IETF Internet Draft

The Common Intrusion Detection Signatures Standard is intended to be a standard format of signatures used widely in Network Intrusion Detection Systems (NIDS). An IDS is controlled by a set of decision rules. A decision rule of an IDS is composed of two components: a description of specific characteristics of an intrusion attempt (a signature) and an action that has to be carried out when the data provided by IDS sensors matches the signature. This document focuses on the remaining part of an IDS decision rule: the IDS signature. Currently, every IDS uses a different format of signatures. CIDSS defines a common format of signatures that attempts to express all information contained in signatures of various IDS. The CIDSS signature format is based on XML to facilitate the adaptation and applications of the proposed standard. The CIDSS signature format is designed to be extensible, and therefore it should be simple to incorporate features of future and current IDS systems that have not been taken into account in the first design. The main goal of CIDSS is to enable administrators of IDS systems to share, compare, evaluate and criticize signatures used to detect intrusion events. The increasingly dynamic, global, and frequent nature of intrusion attempts is a trend that forces administrators to greater efforts to protect increasingly valuable information. The possibility to disseminate knowledge and experience about IDS systems' operation would be enhanced by the introduction of a common signature format. Therefore the use of a common IDS signature format should lead to a greater security of information.. CIDSS meets XML ver. 1.0 requirements. CIDSS is defined as a dialect of XML using the XML Schema Definition (XSD). A CIDSS document is a collection of signatures. Each signature is independent, and can be stored in a separate CIDSS document or together with other signatures. The main XML element of a CIDS document is the "Signatures" element. [Note also the IDS Signature Translator Project.]

See also: CIDSS references


Google Plunges Into Browser Market
Jeffrey Schwartz, Application Development Trends

Google has released the first beta of its new browser, which it calls Chrome, and is set to offer preview releases in 100 countries. In so doing, Google hopes to shake up a browser market now dominated by Microsoft's IE, Mozilla Foundation's Firefox and to a lesser extent Apple's Safari. Chrome takes advantage of WebKit, the open source rendering engine also used in Google's forthcoming Android platform, which the company is rolling out for mobile handsets. Google is also using components of Mozilla Firefox, among other open source components. The company said it will also share its code with the open source community. Google said WebKit makes more efficient use of system memory than other Web rendering engines. "We believe we can add value for users and, at the same time, help drive innovation on the Web," said Sundar Pichai, Google's vice president of product management and Linus Upson, the company's engineering director, in a blog posting announcing Chrome. Google describes Chrome as a browser with a simple interface, in the same model as its search UI. However, the company argues that its open source browser components can run complex Web apps faster and more reliably than others. Among other things, Google says Chrome isolates each browser tab in its own sandbox, preventing the entire browser from crashing when one page fails, although rivals have taken similar steps to isolate tabs within browsers. Google also says Chrome offers a more powerful JavaScript engine, which it calls V8. According to Google, the V8 JavaScript engine examines the JavaScript source code and instead generates machine code that can run directly on the processor. Analysts today said Google faces an uphill battle in making a dent in the browser market... Google took the unconventional approach of describing how Chrome works in an online comic strip. The strip illustrates the issue related to asynchronous APIs that rely on single threaded JavaScript sessions, which lock up browsers until the session is complete. Rather than develop a multithreaded browser, Google said it developed Chrome to employ multiple processes, each with its own memory...

See also: Google Chrome features


Best Practice Recipes for Publishing RDF Vocabularies
Diego Berrueta and Jon Phipps (eds), W3C Technical Report

Members of W3C's Semantic Web Deployment Working Group have published a Group Note for "Best Practice Recipes for Publishing RDF Vocabularies." The document is intended for the creators and maintainers of vocabularies in RDFS and OWL (vocabulary and ontology are used interchangeably in the context of this specification). It provides step-by-step instructions for publishing vocabularies on the Web, giving example configurations designed to cover the most common cases. This 'cookbook' provides recipes describing the steps needed to publish a vocabulary on a Web server, and to configure the Web server to support Semantic Web applications. The section 'Choosing a recipe' provides guidance for choosing the most appropriate recipe depending on the situation and requirements. Once the recipe has been chosen, the reader can follow the steps, adapting the examples for a particular vocabulary. All of the recipes give example configurations for the Apache HTTP server. For those not already familiar with Apache configuration, the appendix on Apache configuration provides a short introduction to the Apache configuration mechanisms used in the examples and basic information on troubleshooting. While the provided configuration examples are specific to an Apache HTTP server, the general principles apply to non-Apache environments as well. The Working Group invites contributions of additional bindings for non-Apache servers. The W3C has provided a wiki page to collect these non-Apache bindings and recommendations. This document is primarily intended for creators and maintainers of existing vocabularies who are looking for guidance on how their vocabularies should best be published on the Web. It is not intended to provide detailed and exhaustive guidance on choosing an appropriate URI namespace for naming a new vocabulary and its constituent terms. However, some basic technical information about URI namespaces, including some considerations relevant to choosing a URI namespace for a vocabulary, is given in the section on URI namespaces...

See also: the W3C Semantic Web Deployment Working Group (SWD)


Public Review for OASIS CIQ Specification Version 3.0
Staff, OASIS Announcement

OASIS has announced a 15-day public review for the "Customer Information Quality Specifications Version 3.0: Name (xNL), Address (xAL), Name and Address (xNAL) and Party (xPIL)." Public Review Draft 03 supercedes the OASIS CIQ V3.0 Committee Specification released in November 2007. This specification includes changes to OASIS CIQ V3.0 xAL schema (both for default code list and genericode approaches). The changes to xAL V3.0 schema is documented as 'OASIS CIQ v3.0 xAL Schema (xAL.xsd) Changes.doc' under the 'supp' directory of the specification package. CIQ Version 3.0 defines Name (xNL), Address (xAL), Name and Address (xNAL), and Party Information (xPIL) specifications. In addition to the specification and schemas, several additional documents are included: Frequently Asked Questions (FAQ); General Introduction and Overview; Package Overview; Release Notes; Technical Overview. CIQ supports party data (names, address and party centric information) ir-respective of countries, cultures, races and geographical locations. Flat XML data models are used as opposed to complex hierarchical XML data models with supporting UML models. It provides the ability for user to define semantics to the data to meet their requirements without modifying the data model and thereby, ensuring the represented data conforms to the CIQ XML schema specifications. In CIQ one may use any code lists without modifying the CIQ XML schema specifications using the upcoming open industry standard for Code List namely the OASIS Code List (Genericode) from OASIS Code List TC and the UBL Methodology for Code List Value and Validation. CIQ supports the ability to define business rules to constraint the CIQ XML Schema specifications without modifying the CIQ XML schema specifications using industry standard approach and industry standards. This feature enables users to restrict the CIQ data models to their specific needs and at the same time ensuring that the represented data conforms to the CIQ data models. A country can apply this feature to constrain the CIQ Address data model to its specific country address data model without modifying the CIQ Address model. One may use GeoRSS/GML from the Open Geospatial Consortium to represent location coordinates.

See also: Markup Languages for Names and Addresses


Sam Ramji: Microsoft's Man in Open Source
James Maguire, InternetNews.com

In this article, Redmond's senior director of platform strategy talks about the software giant's approach to Linux-Windows cooperation, competition and coexistence. Sam Ramji is a busy man. As Microsoft's senior director of platform strategy, his job is a big one: overseeing the company's initiatives in Linux and open source. As Ramji wrote on his LinkedIn profile: "Open Source Software projects and ISVs should contact me to initiate a relationship with Microsoft. I am focused on narrowing the gap between the Open Source community and Microsoft through research, collaboration, interoperability, and community engagement." It's Sam Ramji's job to build a bridge between these two contrasting worlds. To that end, he does things like attend the recent open source confab OSCON, where he spoke about areas of interoperability. He facilitates technical collaborations between Microsoft and open source vendors; past examples include JBoss, SugarCRM, XenSource, Zend and SpikeSource. And he's involved with Microsoft's Open Source Software Lab (launched in 2004), a research project located in Redmond with hundreds of servers running dozens of Linux distros. He maintains a blog about Microsoft and open source. Excerpts from the inteview (Ramji): "Over the course of the past few years, you can certainly say that Microsoft's open source strategy has evolved. The force behind this evolution is both an increased technical expertise and deep line of sight into Linux and open source, which has really helped Microsoft understand where the company competes with commercial Linux offerings and where it can cooperate with the open source community. Microsoft's open source strategy is built on participation with individuals, communities and businesses... Our open source strategy, now and in the future, is to continue a journey in which we participate with others in learning how open source products and technologies, Microsoft products and technologies—and sometimes open source products and technologies from Microsoft—can coexist, combine, and comingle in ways that offer value to customers, developers and IT administrators, partners businesses, and, as a commercial company, our shareholders. But our strategy remains unchanged. Microsoft competes with Linux and Unix servers with Windows servers; we're going to find ways to interoperate between Linux and Windows because lots of our customers run both; and we want to grow the open-source ecosystem as it relates to Microsoft software..."


Develop a Mobile RSS Feed the Easy Way
Vladimir Khomutov, DevX.com

If you've decided to try building a mobile application, you might be looking for a lot of control over the user experience and you'd also like access to various device features: sound, camera, local storage, and so on—features to which you normally would not have access in a web-based application. The first issue you face is deciding upon a platform. While there are several major platforms, the biggest by far is J2ME. Because of it's market share, you choose this platform. Looking at your J2ME options, you'll see that, even if you program in J2ME, mobile phones come in different configurations. This impacts screen size and resolution and buttons and keyboard layouts, among other things. You've probably already realized that it's going to take a lot of code to create something useful, and then you'll have to port your app to all the different platforms out there. Presuming you'd rather spend your time developing than testing and porting, it would be worth your time to check into Breeze, a new J2ME development platform from called Cascada Mobile. With Breeze, you build your mobile app in J2ME, but you develop in HTML and JavaScript. Breeze supports DOM and CSS, which gives you control over look and feel, and also allows you to create internet-connected applications. Best of all, the price is right: Breeze is free. You can even distribute your new mobile application for free at the Breeze Application. Sounds too good to be true? This article will walk you through the development of a simple mobile RSS feed, built using the Breeze platform. Installing Breeze pretty straightforward: you can use a standalone simulator, or an Eclipse plug-in. Breeze ships with the source code for a sample application which is a nice tutorial, and everything you need, in terms of documentation, can be found here. With the Eclipse plug-in installed, create a new Breeze project and the basic app template is set up for you. Next, use HTML to create your basic layout. You could do this in any editor, and even just preview it in a desktop browser, but you might as well make sure it looks good on a phone right from the start. So, grab a logo, and put some HTML in to place it on the screen, and then set up a spot for your text to appear. To add some nice CSS to the application, you can also go ahead and set up some DIV and class information... Using your basic web development skills to build apps, you avoid the hassles of learning the your way around J2ME. This saves time, money, and headaches.

See also: the Java ME Platform web site


Sponsors

XML Daily Newslink and Cover Pages sponsored by:

IBM Corporationhttp://www.ibm.com
Oracle Corporationhttp://www.oracle.com
Primetonhttp://www.primeton.com
Sun Microsystems, Inc.http://sun.com

XML Daily Newslink: http://xml.coverpages.org/newsletter.html
Newsletter Archive: http://xml.coverpages.org/newsletterArchive.html
Newsletter subscribe: newsletter-subscribe@xml.coverpages.org
Newsletter unsubscribe: newsletter-unsubscribe@xml.coverpages.org
Newsletter help: newsletter-help@xml.coverpages.org
Cover Pages: http://xml.coverpages.org/



Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/newsletter/news2008-09-02.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org