Cover Pages: XML Daily Newslink: Tuesday, 01 May 2007

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:
BEA Systems, Inc. http://www.bea.com

Headlines

Expose LDAP Directories to the Semantic Web with SquirrelRDF
Best Practices for XML Internationalization
BEA Blending Dev Tools in Workshop Release
Content Assembly Mechanism (CAM) Version 1.1 Submitted for Approval as an OASIS Standard
WSRP and the Future of Grid Portals
How UML is Used: Many UML Projects Are Not Use Case Driven
System Prototype and Verification Using Metamodel-Based Transformations

Expose LDAP Directories to the Semantic Web with SquirrelRDF
Wing Yung, IBM developerWorks

The Semantic Web has promised a new age of data sharing and integration through use of a common flexible standard, RDF (Resource Description Framework). RDF's properties make it easy to merge data and query across data from different sources. A great amount of data exists in other formats, like XML, relational databases, and LDAP directories. RDF is flexible enough to represent any of these other formats. However, to convert existing data to RDF is a huge and expensive task, and is unnecessary in many cases. Several utilities are available to expose existing data as a Web endpoint queryable through SPARQL, the query language of the Semantic Web. One of these utilities is SquirrelRDF, an open source utility that is part of the Jena Semantic Web framework. The goal of this article is to explain the process of creating a SPARQL-queryable endpoint for an LDAP directory, introducing important Semantic Web concepts along the way. With a little bit of effort, you made LDAP queryable with SPARQL. Making data sources look like RDF makes it much easier for an application to integrate this data with data from other sources, and it gives you a powerful means to query the data. There are several important differences between RDF and XML. First of all, RDF is graph-based, while XML is tree-based. RDF has no explicit ordering because the edges form a set, but XML elements do have ordering. Finally, RDF is a data model that does not include a standard serialization. RDF can be serialized to several formats, including RDF-XML, n3, and Terse RDF Triple Language (Turtle).

Best Practices for XML Internationalization
Yves Savourel and Diane Stoick (eds), W3C Technical Report

W3C's Internationalization Tag Set Working Group has published an updated Working Draft for "Best Practices for XML Internationalization." These best practices are a complement to the International Tag Set W3C Recommendation. The document provides a set of guidelines for developing XML documents and schemas that are internationalized properly. Following the best practices describes here allow both the developer of XML applications, as well as the author of XML content to create material in different languages. Not all internationalization-related issues can be solved with special markup described in the International Tag Set W3C Recommendation; there are a number of problems that can be avoided by designing correctly the XML format, and by applying a few guidelines when designing and authoring documents. For example, include 'xml:lang' in your DTD, XSD schema, or RELAX-NG schema to allow to specify the natural language of the content' make sure the 'xml:lang' attribute is available for the root element of your document, and for any element where a change of language may occur. The scope of the 'xml:lang' attribute applies to both the attributes and the content of the element where it appears; therefore one cannot specify different languages for an attribute and the element content. It is not recommended to use your own attribute or element to specify the language content. The 'xml:lang' attribute is supported by various XML technologies such as XPath and XSL—e.g. the lang() function. Using something different would diminish the interoperability of your documents and reduce your capability to take advantage of some XML applications. Note: This document is still in an early draft stage. Feedback is especially appreciated on the guidelines listed, and when applicable, the mechanisms defined for the selection of ITS specific information in XML documents.

BEA Blending Dev Tools in Workshop Release
Paul Krill, InfoWorld

BEA Workshop 10.1 combines the company's Workshop for WebLogic and Workshop Studio products. The product merges existing developer tools with Eclipse-based NitroX technology, which BEA acquired when it bought M7 in 2005. According to the announcement, BEA Workshop 10.1 is designed to provide Java Enterprise Edition (Java EE) 5 tooling support to help accelerate and radically simplify application development. An integrated Object/Relational Mapping Studio can deliver superior EJB3/JPA, BEA Kodo, OpenJPA and Hibernate tools for Eclipse. The product also includes the unique AppXRay technology and WYSIWYG development capabilities designed for open source and industry standard frameworks including Java Server Faces (JSF), Struts/Tiles, Spring, JSP/JSTL, EJB3/Hibernate, Apache Beehive and others to further help simplify development and increase overall productivity. A full drag-and-drop integrated development environment (IDE) for building enterprise-class services on BEA WebLogic Server as well as a single point of management for builds, build reporting and build documentation for the open source maven build system are also new features in Workshop 10.1, showing the mix-and-match philosophy of blended in action. BEA Workshop also supports other application servers like those from IBM, JBoss/Redhat, as well as open source servers like Apache Tomcat.

Content Assembly Mechanism (CAM) Version 1.1 Submitted for Approval as an OASIS Standard
Staff, OASIS Announcement

The OASIS Content Assembly Mechanism Technical Committee voted to submit its CAM Version 1.1 specification to the membership for approval as an OASIS Standard. The Content Assembly Mechanism (CAM) provides an open XML based system for using business rules to define, validate and compose specific business documents from generalized schema elements and structures. A CAM rule set and document assembly template defines the specific business context, content requirement, and transactional function of a document. A CAM template must be capable of consistently reproducing documents that can successfully carry out the specific transactional function that they were designed for. CAM also provides the foundation for creating industry libraries and dictionaries of schema elements and business document structures to support business process needs. The core role of the OASIS CAM specifications is therefore to provide a generic standalone content assembly mechanism that extends beyond the basic structural definition features in XML and schema to provide a comprehensive system with which to define dynamic e-business interoperability. The CAM work can be used in conjunction with and by other OASIS TCs to formalize use patterns and templates for their own schemas or to generate / validate policies such as SAML and XACML assertions. CAM implementations can provide validation web services for registry or general transaction exchanges for industry standards groups use. Related external work includes ISO/IEC 19757-3:2006 Schematron and the W3C XSD work and the W3C SML submission, along with work by UN/CEFACT on UCM and CCMA.

See also: the announcement

WSRP and the Future of Grid Portals
Xiaobo Yang, Xiao Dong Wang, Robert Allan; IBM developerWorks

This three-part series on the development of standards-based grid portals provides an overview of grid portals, focusing on today's standards-based second-generation grid portals: JSR 168 and Web Services for Remote Portlets (WSRP) V1.0. JSR 168 and WSRP V1.0 are two specifications that aim to solve interoperability issues between portlets and portlet containers. In particular, today's grid portals are service-oriented. On one hand, portals are acting as service clients to consume traditional data-centric Web services. On the other hand, portals are providing presentation-centric services so federated portals can be easily built. With basic grid related functions like proxy manager and job submission successfully implemented, advanced grid portals today are aimed at the integration of complex applications, including visualisation and workflow systems. When we talk about adoption of SOA for portal development, one of the key concepts is that presentation logic can be integrated with business logic and provided as a service. The WSRP V1.0 specification standardises how portlets can be exposed to remote portlet containers using Web services technology. In WSRP, a producer is modelled as a portlet container within which portlets reside. Such a producer acts as a service provider, while at the same time, various clients are able to consume this service through which portlets are evoked. Although the Apache WSRP4J project initiated by IBM is still in its incubation phase, the WSRP4J producer is, in our experience, more practical than WSRP producers from other open source portal frameworks, such as the eXo platform and Liferay. Therefore, we selected WSRP4J to illustrate how grid portlets we developed in this series can be reused in other systems, allowing WSRP-equipped consumers to benefit from having grid tools without local development. The WSRP4J producer uses Pluto, the Reference Implementation of JSR 168 provided by Apache, as its portlet container.

How UML is Used: Many UML Projects Are Not Use Case Driven
Brian Dobing and Jeffrey Parsons, ACM Queue and CACM

The Unified Modeling Language (UML) emerged in the mid-1990s through the combination of previously competing object-oriented (OO) software engineering methods developed by Booch, Jacobson et al., Rumbaugh et al., and others. Control over its formal evolution was placed in the hands of the Object Management Group (OMG), and the language has become widely accepted as a modeling standard for OO software development. UML should not be considered exclusively as a language for software professionals; a greater understanding of UML diagrams and their roles in building systems is needed throughout organizations. Standardization of UML has made a major contribution toward this goal; standardization of usage guidelines is needed as well. Summary: (1) The frequency of use of UML components varies considerably: Class, Sequence, and Use Case Diagrams are used most often, while Collaboration Diagrams are used least. (2) Apparently, at least half of UML projects are not Use Case driven: Class Diagram use substantially exceeds Use Case Diagram and Narrative use. (3) Contrary to claims in the popular literature, developers appear to believe that UML diagrams can be understood by clients: Clients are most involved with Use Case Narratives and Activity Diagrams, but are more involved with the remaining components than we expected. (4) While systems analysts and programmers rely most on Class and Sequence Diagrams they also use the Use Case Narratives, suggesting that the potential communication disconnect may not be a concern in practice. (5) Use Case Narratives appear not to capture all requirements: Class, Sequence, and Statechart Diagrams provide the most additional information beyond Use Case Narratives.

System Prototype and Verification Using Metamodel-Based Transformations
Luis Pedro, Levi Lucio, Didier Buchs; IEEE DS Online

Mapping domain-specific languages' core concepts into the Concurrent Object-Oriented Petri Nets formal specification language provides users with the semantics necessary for developing prototypes for these DSLs. DSLs are less comprehensive than general-purpose languages (such as C++ or Java) but much more expressive in their domain, letting domain experts understand, validate, modify, and often develop DSL programs themselves. The article discusses transformation of a DSL into the Concurrent Object-Oriented Petri Nets formalism. The DSL metamodel serves as the transformation's starting point. The transformation represents the semantic mapping between the DSL and CO-OPN. "The CO-OPN object-oriented modeling language is based on abstract algebraic data types (ADTs) and Petri nets. It provides a syntax and semantics that let developers use heterogeneous object-oriented concepts for system specification. The specifications are collections of ADTs, classes, and contexts—the CO-OPN modules. We use the Meta-Object Facility (MOF) or Eclipse Modeling Framework (EMF) Ecore formalism to define the metamodel. For prototype generation and execution, we transform CO-OPN specifications into a Java package including ADT classes and JavaBean-like components. CoopnBuilder also provides a prototype simulation environment via Java reflection functions. It lets users interpret the prototype as it's integrated into an application. Graphical simulation lets users manually explore the system's state space. For systems with large state spaces, users can dump the complete simulation trace into an XML file and use automatic analysis tools to deduce properties such as the coverage of state space during the simulation."

See also: XML and Petri Nets


SEARCH \| ABOUT \| INDEX \| NEWS \| CORE STANDARDS \| TECHNOLOGY REPORTS \| EVENTS \| LIBRARY

Headlines

Sponsors