Cover Pages: XML Daily Newslink: Wednesday, 25 March 2009

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

Headlines

Requirement for Web-Friendly, Reusable Graphics: SVG in ODF
Community Discussion: XML Format for vCard
Encryption Keys Multiply Like Rabbits
Opera Implements Geolocation API Specification
James Clark: Getting Involved With [Oslo Modeling Language] M
Google Docs Gets Collaborative-Drawing Feature

Requirement for Web-Friendly, Reusable Graphics: SVG in ODF
Doug Schepers, Posting to OASIS Comment List

Doug Schepers posted a "Requirement: SVG Integration" request for first class SVG support in ODF. Background, from the W3C wiki document: "SVG in the OpenDocument Format dates back to 2005, when the OpenDocument TC, a technical committee in OASIS, decided to use SVG in the OpenDocument office format. Rather than use SVG as specified, however, they merged it with their own custom format Draw/Impress. They decided that many SVG-defined attributes were useful, but not the elements. Not realizing that SVG attributes are in the null namespace, they applied these attributes to Draw elements but put them in the SVG namespace. Right now, ODF (and more specifically, the OpenOffice.org implementation) only supports SVG as an import and export format, not as a native format. An OOXML developer, Jesper Lund Stocholm, wrote a blog entry with in-depth analysis of this support, and determined that there doesn't seem to be true SVG support. Inkscape also has compiled a list of correspondancies between ODF Draw and SVG..." Doug wrote in the request: The W3C SVG Working Group applauds the OpenDocument TC for their decision to use SVG, by adopting some SVG elements and attributes. As we understand it, one goal of the ODF specification is to reuse existing specification where appropriate, and in this case, it makes sense to specify complete support for SVG 1.1 and SVG Tiny 1.2 as they are specified, rather than only as part of ODF Draw format. In the next version of the ODF specification, there should be support for SVG as a regular image and as vector graphics (or "line art"), in addition to the ODF Draw format. With native SVG support, ODF would enjoy several "network effects" though the increasing prevalence of SVG among authoring tools and viewers. Developing and maintaining ODF implementations would be made simpler, since there are many existing open-source SVG libraries, in both C and Java. In contrast to ODF Draw format, SVG is inherently web-publishable, with native support in Firefox, Opera, Safari, and Google Chrome, and in Internet Explorer through plugins or script adaptions. While OOo currently supports SVG as both an import and export format, this extra step makes effective round-tripping more difficult, with regards to using existing content, and editing in Inkscape, Illustrator, CorelDraw, Xara, and other major graphics authoring tools... We feel that this is a pivotal opportunity for open document formats, and that a synergy between ODF and SVG will work to everyone's benefit. Please let us know any issues or factors that would make adopting SVG as a first-class component of ODF difficult. We may be able to help remove barriers or clarify confusion..."

Community Discussion: XML Format for vCard
Zoltan.Ordogh (et al.), IETF Discussion List Posting

Several participants in the IETF vCard and CardDAV (VCARDDAV) Working Group have expressed (renewed) collective opinion about making XML a normative format for vCard. Excerpts: [1] Zoltan.Ordogh (Nokia) "It's been on my mind for a while now, but never had the courage to ask. I mean no harm, but I never really understood what's the reason for having plain text syntax for vCard. Is there a really good reason to maintain the plain text representation any futher? Just for the sake of history, there is no need. I think most clients/servers can handle XML without any issues. Wouldn't the XML-based representation be enough?" [2] Barry Leiba: "Zoltan thinks we should switch to XML as the only format for vcards, and eliminate the historical format. I agree." [3] Peter Saint-Andre: "+1. From my perspective this would have the added benefit of helping us deprecate vcard-temp (the 'vcard-temp' document provides canonical documentation of the vCard-XML format in use within the Jabber community as of 2008-07-16) in the XMPP community..." [4] Joseph Smarr: "Yeah, I also agree we should try to get most new developers using an XML/JSON serialization of vCard, since every language has robust parsers for these formats, whereas parsing and generating vCard's archaic custom format is definitely a roadblock for lots of people. Trust me, we've spent a lot of time helping other companies we interop with debug their vCard stuff, and library support in the wild is very uneven. That being said, I think the existing format is going to be around for a while, and that's fine, esp. if we have good transformers to/from JSON/XML. But when you also bring in hCard etc., it becomes clear (at least to some of us) that the primary contribution of vCard is the namespace and standard semantics (e.g., this is how you describe a name or phone number) and not the particular historical serialization they chose over a decade ago..." [5] Cyrus Daboo: "Right—lets get vcard 4.0 out using the current data format then define XML/JSON formats that people can transition to or start using from scratch if they need to." [6] Barry Leiba: "I worry more than that. I think that if we're doing to deprecate the old format, we'll do best to do it now. People will upgrade to this version of VCard and switch to XML at the same time. If we still have the antique format, they'll move that way, and it will take a long longer to switch to XML. A LOT longer..."

Encryption Keys Multiply Like Rabbits
Storagezilla (Mark Twomey), Byte and Switch Posting

This posting is a response to Howard Marks' article, "Let's Bring Sanity to Disk Encryption", published March 23, 2009. Marks had said: "Given the cost and complexity of today's solutions, I'm not sure solving the drive disposal problem is a good enough reason to invest in SAN encryptors... The overhead of storing encryption keys for several hundred drives, and retrieving them on array startup, should be minimal. The real work of encrypting and decrypting data happens in each drive, so it is the job of Seagate or Hitachi Global Storage Technologies to make it fast..." Storagezilla replies: "It's not that cut and dried, and things start getting complex if you have array level replication going on as you'll need access to the key on the other side to read the data on the replica. Which means you're no longer dealing with just one domain per device. If you want end to end encryption you might be doing it in the app itself and for legacy gear you might be using software or HBA encryption and before we know it anyone with a large amount of gear on the floor has keys coming out their ears all managed through how many interfaces to whatever number of devices involved. I get the point, encryption should be built in and not bolted on and that's true of all security but encryption keys are like rabbits and before you know it you're up to your neck in them. That's why the Key Management Interoperability Protocol (KMIP) is so important going forward. Yeah, build in encryption, and yes, offer to store and manage the keys locally, but via KMIP make sure you can easily tie them all back to an Enterprise Key Manager so you're not burning cycles managing a couple of keys per device across a lot of devices. That's not the best use of anyone's time..."

Opera Implements Geolocation API Specification
Max Froumentin, Blog

"We [Opera] are delighted to release the first build of Opera with geolocation support. The geolocation Working Group of the W3C has recently relased the first Working Draft of the geolocation API specification, and we are now releasing the first Labs build with support for the API. The API is used in a web page's Javascript code to retrieve the current latitude and longitude of the browser. the API is very simple, and doesn't get much more complicated with more advanced functionality. Geolocation on the web is not new. Many sites already use the IP address of the browser to serve targetted content, mostly ads (you will have seen the 'Find a Friend in [your city]' banners). However, that method is notoriously inaccurate and cannot be reliably used for more advanced geolocation services. On the other hand, the device which the browser is running on is more likely to have an accurate idea of its location if it has a GPS unit or can triangulate the wireless access points or cell towers, or look up its IP address. Even if the device doesn't have the right hardware, a location provider web service can be used. This build uses the Skyhook service, and therefore you will need to register your site on 'loki.com' in order for your geo-enabled web application to be allowed to request the locations of users. Additionally, if you're running Windows XP you will also need to run 'svcsetup.exe', which ensures that wifi scanning will not be affected by various "wifi managers" that are shipped with many laptops. All this won't be necessary in future releases... The W3C Geolocation API is likely to become a widely adopted standard, and Opera is providing this early implementation of the API to let developers and users start experimenting with it. We would be very grateful for feedback from both developers and users, on the API itself and on what functionality and level of privacy control you would like to see exposed in the user interface..."

James Clark: Getting Involved With [Oslo Modeling Language] M
James Clark, Random Thoughts (Blog)

I spent last week in Redmond talking to Microsoft about M ["M" Language Specification] and Oslo. The question at the back of my mind before I went was "Does M really have the potential in the long term to be an interesting and useful alternative to XML?". My tentative answer is "yes". Here's why: (1) Although M, as it is today, is interesting in a number of ways, it is obviously a long way from being a serious alternative to XML—at least for the kinds of application I am interested in. One of my concerns was that I would hear "It's too late to change that". I never did: I was pleasantly surprised that Microsoft are still willing to make fundamental changes to M. (2) Microsoft recognize that M's long-term potential would be severely limited if it was a proprietary, Microsoft- only technology. I believe they realize that M needs to end up as a genuinely open standard... (3) Microsoft is addressing the whole stack. An alternative to XML needs to provide not only an alternative to XML itself, but also alternatives to XSD/RELAX NG and XQuery/XSLT. (4) Microsoft seem to be designing things in a principled way; they are paying attention to the relevant CS theory. For example, ML seems to be a major influence. They are making an effort to produce something clean, elegant, even beautiful, rather than doing just enough to get a product out. Microsoft seem willing to take documents seriously. This is a make or break issue for me, because the kind of data I care about most is documents and M, as it is today, is not useful for documents. This was probably the issue we spent the most time on; I talked a lot about the importance of mixed content. One of the Microsoft team suggested the goal of using M to do the M specification. It's early days yet, and it's hard to tell how much leverage M will get, but there's enough potential to make me want to be involved...

See also: the M specification

Google Docs Gets Collaborative-Drawing Feature
Stephen Shankland, CNET News.com

Google has added a basic drawing ability to Google Docs, letting people add graphical elements such as org charts or diagrams to their online word-processing documents, spreadsheets, and presentations. You shouldn't expect to be able to crowdsource your online document into something fit for the Guggenheim, but the feature does offer several useful illustration tools that can be used within Google Docs' multi-author collaborative framework. [...] According to the blog article by Tony Glenning: "It's easy to create drawings using lines, free hand scribbles, text labels and a large choice of shapes that you can move, resize, rotate and adjust. Group, order, align and distribute and other features are available when you select objects you've drawn. You can also customize a range of shape properties, from line widths to fill color, and from arrowheads to font size, and much more. If you change your mind, there is undo and redo. You can collaborate with a friend or colleague on a drawing, or work alone, just as you can in Google Docs today... The team and technology behind Insert Drawing originally came from the startup Tonic Systems, which Google acquired in 2007. The drawing feature that we've built relies heavily on a relatively new capability in browsers: the ability to render vector graphics. We use the SVG (Scalable Vector Graphics) standard to accomplish this in most browsers and VML (Vector Markup Language) where SVG is not available. Only recently has the performance and ubiquity of such technology enabled us to deliver what we hope is a delightful feature. As browsers continue to improve, we can deliver more and more useful cloud-based functionality. As with any new feature, we'll be adding new capabilities over time. But even though we have our own to-do list, we'd love to hear about how you think we could improve drawings..."

See also: the blog article


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

Headlines

Sponsors