Tag Archive for: XML Schema

Comparing XML Schemas with DiffDog 2010


DiffDog 2010 includes a powerful new tool to compare XML Schemas that XML developers and others can use to update existing XML data files as XML Schemas evolve. This post takes a look at an example scenario for this feature.Before we drop into the new functionality, let’s take a quick look at two XML Schemas using the DiffDog File Compare feature. Of course, just like in previous versions, DiffDog 2010 users can compare XML Schemas as .xsd documents and display differences in a color-coded, XML-aware format.DiffDog file comparison view of XML Schemas This is a good way to identify and manage differences in XML Schemas, especially when you want to review revisions to industry-standard XML Schemas that evolve over time.What’s new in DiffDog 2010 is an additional XML Schema Differencing option that graphically displays two XML Schemas side by side, identifies identical elements automatically, and lets users map differences and generate XSL transformations to update XML data files.Here’s our first view when we open the same two XML Schemas shown in the file comparison above, using the new XML Schema Differencing feature.Initial DiffDog XML Schema Differencing view of XML Schemas The root elements of the two XML Schemas are automatically connected. We can click the Compare button in the toolbar to automatically connect identical elements in the two XML Schemas.DiffDog XML Differencing (Of course we could also select Compare XML Schemas from the right click context menu, or choose Start Comparison from the Diff and Merge menu, or press the F5 keyboard shortcut – DiffDog gives you many options to perform the same task, so you can work the way you like.)Next, we can map elements with different names in the two XML Schemas by manually connecting the pointer arrows between them. In this example most of the changes to the version of the XML Schema on the right simply give elements new names that will be more clear when the XML Schema and its data files are distributed through our enterprise.User-mapped XML Schemas in DiffDog XML Schema Differencing view When all the elements are mapped, we can generate an XSLT file to transform existing XML data files based on the XML Schema on the left to reflect revisions in the newer version on the right. This feature is designed to rescue XML developers from the tedious tasks of writing and debugging XSL transformations by hand.DiffDog Diff and Merge Menu Here is an example of an original XML data file based on the XML Schema on the left side, as viewed in Altova XMLSpy:XML data file viewed in XMLSpy The output file after applying the XSL transformation we created with DiffDog 2010 appears below. Note the substitution of the author element for writer, email for feedback, and so on.XSL output viewed in XMLSpy If there are many existing XML files that need to be transformed, the Project Management features of XMLSpy can help us automate the process. We can add external folders to an XMLSpy project.XMLSpy Project Helper Window Using the XMLSpy properties dialog for each project folder, we can assign default values to assign an XML Schema for validation, the XSL transformation, and the destination of the output.XMLSpy project folder properties dialog Now we can select the input folder in the XMLSpy Project helper window and transform all the files in it with the single-keystroke F10 shortcut.When we originally mapped the XML Schema elements in DiffDog, we left the publication element on the left side unconnected, since it had no corresponding element in the earlier version of the schema. That means when we transform XML input files using the XSLT, the resulting output will not contain the publication element. If publication is a required element, we can call on Altova MapForce for a quick solution.One of the options in DiffDog is to generate a MapForce mapping rather than XSLT. When we choose this option, MapForce launches with our DiffDog mapping already loaded as a new MapForce design, as shown below.MapForce New Design It’s easy to enhance the mapping by adding a constant as a default value for the publication element.MapForce enhanced design Now we can save an XSL file from MapForce that reuses all the element mappings we originally designed in DiffDog and adds the constant. When we apply the new XSL to transform our original XML data file, we get a result that includes the default value for the publication element.Final version of output viewed in XMLSpy This post started by describing the new XML Schema Comparison feature in DiffDog 2010. Fleshing out a simple – but typical – real-world example quickly highlighted additional tasks easily completed by taking advantage of tight integration with XMLSpy and MapForce.All three of these tools and more are available at substantial savings in the Altova MissionKit 2010, the integrated suite of XML, database, and UML tools designed to meet the diverse development and data management needs of today’s software architects and XML developers. Click here to download a free trial today!

Tags: , , , , , , , , ,

What's New in XMLSpy 2009?


In addition to being tremendously useful, some of the new features in XMLSpy 2009 are just plain cool. The complete list of new functionality includes:

  • Support for XBRL 2.1 and XBRL Dimensions 1.0  
  • XBRL Taxonomy Editor
  • XPath auto-completion 
  • Native support for additional databases 
  • Support for XML fields in SQL Server
  • Extensions for identity constraints editing in Schema View 
  • Expanded source control system support
  • Support for the XSLT extension altova:evaluate  
  • Support for Apache FOP 0.95  

We’ve already blogged quite a bit about the first two items on the list: support for XBRL validation and XBRL taxonomy editing. Some more details on the other new features are below.

Intelligent XPath Auto-Completion

We’ve been delighted to receive feedback from customers who are really excited about this new feature. If you’re developing XSLT or XQuery, writing XPath expressions just got a lot easier. As you’re composing an XPath expression in Text View, Grid View, or the XPath Analyzer, XMLSpy now provides you with valid XPath functions, as well as element and attribute names from the associated schema and XML instance(s). XMLSpy’s intelligent XPath auto-completion accounts for namespaces when listing options and even provides deep path suggestions when the required node is not in close proximity to the current context. XPath auto-completion  

Native Support for Additional Databases

XMLSpy 2009 adds new native support for the latest versions of SQL Server and Oracle, and brand new support for PostgreSQL. Support for DBs in XMLSpy allows you to generate an XML Schema based on a database, import and export data based on database structures, and generate relational database structures from XML Schemas, and so on. The built-in Database Query window lets you perform queries against the database and edit the data. Here’s the complete list of databases with native support in XMLSpy:

  • Microsoft® SQL Server® 2000, 2005, 2008
  • IBM DB2® 8, 9
  • IBM DB2 for iSeries® v5.4
  • IBM DB2 for zSeries® 8, 9
  • Oracle® 9i, 10g, 11g
  • Sybase® 12
  • MySQL® 4, 5
  • PostgreSQL 8
  • Microsoft Access™ 2003, 2007

SQL Server support has also been enhanced to allow viewing and editing of XML fields that are stored in the database.

Extensions for Identity Constraint Editing in Schema View

Configuring identity constraints (i.e., key/keyref/unique values) is an important aspect of XML Schema development, especially for database users. Adding to existing support for editing these identity constraints, there are now enhanced visual cues and editing options in XMLSpy 2009. A new tab Identity Constraints tab in the Components entry helper window displays all existing constraints in a tree view and allows you to easily modify or create new relationships. Furthermore, identity constraints are now indicated by green lines, informative icons, and mouse-over messages in the Content Model View. A right-click menu allows you to easily add new relationships and specify field and selector values by typing them manually, using drop-down entry helpers, or by simply dragging and dropping the desired nodes. Schema identity constraints

Expanded Source Control System Support

Based on customer feedback, we’ve completely reworked the source control system interface in XMLSpy and also added the same level of source control support to UModel, our UML modeling tool, allowing both products to intelligently integrate with all major SCM tools. Once a project is bound to a version control system, XMLSpy automatically monitors the status of all files and prompts the you to check out a file whenever you starts to modify the document. In addition, the actual state of each file is shown through checkmarks or locks in the upper right corner of each file icon.   What do you think of these new features? What would you like to see added to the next version of XMLSpy? Let us know by commenting below.

Tags: , , , , ,

Altova customer Recordare builds MusicXML-based solution


Case Studies

Recordare® is a technology company focused on providing software and services to the musical community. Their flagship products, the Dolet® plugin family, are platform-independent plugins for popular music notation programs, facilitating the seamless exchange and interaction of sheet music data files by leveraging MusicXML. Dolet acts as a high quality translator between the MusicXML data format and other applications, enabling users to work with these files on any conceivable system, including industry leading notation and musical composition applications Finale® and Sibelius®. The list of MusicXML adopters also includes optical scanning utilities like SharpEye or capella-scan, music sequencers like Cubase, and beyond. Dolet increases the MusicXML support in all of these programs and promotes interoperability and the sharing of musical scores. In creating the Dolet plugins, Recordare used Altova’s XML editor, XMLSpy, for editing and testing the necessary MusicXML XML Schemas and DTDs, and the diff/merge tool, DiffDog, for regression testing.

The Challenge

Music interchange between applications had traditionally been executed using the MIDI (Musical Instrument Digital Interface) file format, a message transfer protocol that has its roots in electronic music. MIDI is not an ideal transfer format for printed music, because it does not take into account the multitude of notations (e.g., rests, repeats, dynamics, lyrics, slurs, tempo marks, etc.) that convey much of the meaning. MusicXML is an open, XML-based file format specifically created to encapsulate musical notation or digital sheet music data that was built on top of previous formats, MuseData and Humdrum. XML lends MusicXML the power and flexibility to be easily accessed, parsed, rendered, and otherwise manipulated by a wide variety of automated tools, and its general acceptance as a standard makes it an ideal format for scoring using computer technology. Since its original release by Recordare in January of 2004 (version 2.0 was released in June 2007), MusicXML has gained acceptance in the music notation industry with support in over 100 leading products, and is recognized as the de facto XML standard for music notation interchange. These products would not have adopted MusicXML unless it could be used to exchange data with industry-leading applications like Finale and Sibelius. By developing advanced plugins for popular music notation suites, Recordare would be able to deliver to their customers all of the advantages that XML can bring for data exchange and standardization.

The Solution

Below is an example showing the score of the first few measures of Beethoven’s An die ferne Geliebte, Op. 98 as it is written in sheet music: and a small snippet of the same piece translated to MusicXML: The MusicXML-based Dolet 4 plugins for Finale and Sibelius provide a more accurate and usable representation of sheet music than Standard MIDI translation. For example, the images below show the same piece of music. On the left is a Finale 2009 rendering of a MIDI file exported from Sibelius, and on the right is the same application’s interpretation of a MusicXML 2.0 file exported from the same version of Sibelius.
In the MIDI rendition, vital information like chord symbols, lyrics, slurs, articulations, and even title and composer are omitted from the translation. In addition to providing native support for MusicXML, the recently released Dolet 4 for Finale and Dolet 4 for Sibelius plugins enhance the capabilities of these programs by adding advanced features like:

  • Batch translation
  • More accurate and reliable data exchange
  • More formatting control
  • Support for the MusicXML XML Schema (in addition to the DTD)

In developing the plugins, Recordare was subject to specific requirements dictated by the Sibelius and Finale applications. The Sibelius plugin was programmed in ManuScript, and is one of the largest plugins ever written in that language. Finale, on the other hand, requires plugins to have a C++ core, and Recordare implemented this, adding MusicXML logic in Java and a JNI layer to provide the two-way Java/C++ communication. Recordare’s Dolet plugins are now critical aspects of the music preparation process for many television and film scores as well as new music publications. Errors in translation need to be fixed in maintenance updates, while ensuring that no new errors are introduced into these complex translation plugins. Regression testing of the MusicXML file produced by the Dolet plugins is thus an essential part of Recordare’s quality assurance process. Recordare used Altova’s DiffDog in the development of the Dolet plugins. XMLSpy was used to test and edit their DTDs and XML Schemas, and DiffDog for regression testing the MusicXML files produced by the software. Recordare has several regression test suites covering a wide range of musical repertoire, from baroque to hip-hop. DiffDog allows easy differencing of multiple runs of these test suites, including the ability to ignore differences in XML metadata elements such as software version and XML creation date that always change across test cases. Recordare has used Altova’s XMLSpy XML editor to edit the MusicXML DTDs and XML Schemas, starting with the use of XMLSpy 3.5 (released in 2001) to create the earliest alpha and beta versions of the MusicXML DTD. Version 2.0 of MusicXML added a compressed zip version of the format, similar to what is used in other XML applications like Open Office and Open XML. XMLSpy 2008 Enterprise Edition’s comprehensive support for zipped XML files made it easy to test this new feature together with the Dolet for Finale plugin.

A small portion of the extensive MusicXML schema shown in XMLSpy’s graphical XML schema editor

XMLSpy’s support for XQuery has also contributed to Recordare’s regression testing efforts. In response to a customer request, Recordare now exports XML processing instructions from the Dolet for Sibelius plugin when it encounters a musical feature that it is unable to translate correctly. A simple XQuery execution to search for all the processing instructions in the XML files in a given folder lets Recordare check for the presence of these restrictions within each test suite, and then compare the resulting XML files using DiffDog between runs of the test suite. Recently, customer demand led Recordare to develop an XSD version of the MusicXML format. XMLSpy Enterprise Edition was used to develop and test the schemas. Schema validation, schema restriction and extension, and automatically-generated schema documentation were all able to be tested using XMLSpy’s features.

The Results

The Dolet plugins are extensions for common industry software that harness the built-in capabilities of the MusicXML format to make musical scores truly interchangeable across disparate systems and toolsets. These plugins have the capacity to render accurate and meaningful musical notation based on the powerful MusicXML specification. The leading XML Schema editing capabilities in XMLSpy and the strong XML and directory differencing support in DiffDog enabled Recordare to write and polish the MusicXML schemas and perform regression testing on the Dolet plugins. The resulting high quality of the schemas and software has made MusicXML and the Dolet plugins a key element of the toolkit for composers, arrangers, publishers, copyists, and engravers throughout the industry wherever printed music is used. Try XMLSpy, DiffDog, and the other Altova MissionKit tools for yourself with a free 30-day trial.

Tags: , , , , , , , , ,

Case Study: Equifax


equifax Check out the case study below to learn how leading US credit reporting entity Equifax® built an advanced SOAP interface for their identity verification and authentication Web service.

Overview

Equifax is a leading credit reporting entity and provider of analytical and decision support tools. Their real-time authentication system, eIDverifier, offers government and businesses personalized online security measures that help protect them against fraud and comply with federal legislation. The eIDverifier process is used within e-commerce and other online applications to authenticate users’ identities based on their answers to personalized questions drawn from Equifax’s extensive data stores. The authentication process consists of five steps:

  1. Integrity Check – eIDverifier standardizes and screens applicant-provided information to test for data inconsistencies and irregularities.
  2. Pattern Recognition – A pattern recognition algorithm is conducted on each transaction. For example, a velocity parameter determines the number of times an applicant has applied for authentication in a specific time frame.
  3. Identity Validation – To confirm an identity’s legitimacy, eIDverifier uses a “waterfall” approach in gathering validation information from multiple data sources. This means that if the identity cannot be validated with the first data source, eIDverifier will proceed to the next data source until the identity is validated.
  4. Interactive Query – eIDverifier presents multiple-choice questions to the applicant based upon “shared secret” information that should only be known to the applicant and Equifax. The question sets are customizable to meet individual risk thresholds.
  5. Decision Logic / Output Assessment – There are two output components to eIDverifier – an assessment score and reason codes. The assessment score indicates the likelihood of an applicant presenting fraudulent information, while reason codes provide important details on questionable information and highlight any discrepancies between the consumer’s application information and Equifax data sources.

eIDverifier relies on the SOAP protocol to send messages defining these interactions back and forth between the client interface and the Equifax servers. Third party institutions license the eIDverifier SOAP interface for use within their online application processes, enabling them to integrate its functionality and access information contained in Equifax’s databases.Equifax uses the XMLSpy XML Schema editor to graphically design the XSDs that serve as the foundation for their SOAP interface.

The Challenge

Equifax needed a sophisticated tool for designing the XML Schemas that would define the data types for their Web service, as well as a mechanism for creating the WSDL documents that would describe the interface as a whole. As a Java shop, Equifax needed a solution that would be compatible with their other development tools, and that would work seamlessly with the Eclipse IDE. Though there are plenty of Java tools available that have the capacity for XML Schema development, XMLSpy presented the most attractive option for schema design because of its comprehensive graphical design and editing options.The Equifax development team took a further step to simplify their Web services creation, using XML Beans and the Codehaus XFire/CXF Java SOAP framework to auto-generate WSDL from their XML Schemas.

The Solution

eIDverifier relies on a variety of different technologies to bring identity verification and authentication to its clients. XMLSpy provides the following benefits:XML Schema

XML Schema is used to express the structure of the data, as well as the individual elements and attributes that it is comprised of. Because a large portion of the data relies on end-user input in the form of address, phone number, driver’s license number, etc., it is vital that this information is in a format that can be digested by the system.Using XMLSpy’s graphical XML Schema editor, the Equifax development team was able to easily visualize and maintain the structure of their XML Schema. A portion of the schema that was created appears below:

SOAP interface

This data type definition provides the syntax, and dictates the structure, for the data that is transmitted by the eIDverifier Web service.

XMLSpy’s unique graphical XML Schema editor allowed the Equifax development team to create and maintain a complex schema definition without writing any code manually. They were also able to automatically generate human-readable documentation that can be used to present the architecture for review at any time in the development process, and that describes each element and attribute in detail.SOAP interface

WSDL

The processes executed by eIDverifier are described by a WSDL document that incorporates the XML Schema to provide information about data types, functions, and other interface details to the client – defining and dictating the actions taken by the client application to send and retrieve information between the end-user and the Equifax servers. The Equifax team chose to autogenerate a WSDL document using the Codehaus XFire/CXF framework. The XML Schema was used as the basis for an XMLBeans implementation, which was then compiled as a Java service class. Once the eIDverifier service was exposed, XFire automatically generated a WSDL – the WSDL is shown below in the XMLSpy graphical WSDL editor.

SOAP interfaceThis WSDL serves as the basis for the eIDverifier application, defining the ports and messages that make up the communication infrastructure of the Web service.

The Results

The eIDverifier SOAP interface allows external applications to access Equifax’s backend data stores, exposing it as a Web service and enabling them to retrieve secure information without jeopardizing the integrity of the Equifax mainframe. Utilizing WSDL and SOAP, and surrounded by Java architecture, eIDverifier is able to confirm user identity by returning a set of multiple choice questions based on the secure data maintained by Equifax.SOAP interfaceXMLSpy enabled the Equifax team to quickly and easily create a graphical schema representation and the matching documentation to serve as the basis for the Web service. It also allowed the development team to focus on their Java code, rather than the intricacies of XML Schema and WSDL design. The Altova MissionKit provides numerous tools for advanced Web services development, from the graphical XML Schema and WSDL editing discussed here, to SOAP debugging, and even graphical Web services generation and data mapping. Download a free trial to check it out for yourself.

Tags: , , , , ,