This issue of XML Daily Newslink is sponsored by:
SAP AG http://www.sap.com
- XHTML Access Module: Module to Enable Generic Document Accessibility
- Ten Mistakes Companies Make When Implementing SOA Projects
- XML-based Information Delivery Framework on the Desktop
- Web Applications Format and WS-ResourceTransfer Both Overload Alleged Operation
- A Uniform Resource Name (URN) for Emergency and Other Well-Known Services
- The Design Goals of XML
- Study: Open Document Format Made Gains in 2007
XHTML Access Module: Module to Enable Generic Document Accessibility
Mark Birbeck, Shane McCarron (et al, eds), W3C Technical Report
W3C invites public comment on the First Public Working Draft of "XHTML Access Module: Module to Enable Generic Document Accessibility." The document has been produced by members of the XHTML2 Working Group; it has been developed in conjunction with the W3C's Web Accessibility Initiative and other interested parties. The specification is intended to help make XHTML-family markup languages more effective at supporting the needs of the accessibility community. It does so by providing a generic mechanism for defining the relationship between document components and well-known accessibility taxonomies. XHTML Access is not a stand-alone document type. It is intended to be integrated into other XHTML Family Markup Languages. A conforming XHTML Access document is a document that requires only the facilities described as mandatory in this specification and the facilities described as mandatory in its host language.
See also: the XHTML2 Working Group Charter
Ten Mistakes Companies Make When Implementing SOA Projects
Paul Callahan, eWEEK
A growing number of companies are implementing SOA projects to lower IT integration costs, while improving the time it takes to make changes to business units. However, according to Paul Callahan, manager of technical services at NetManage, of those companies that have begun deployment, many are held up in the early implementation phase. This has resulted in a number of organizations either scaling down or abandoning their SOA deployment plans. "There are fairly common mistakes to avoid when implementing an SOA project, and best practices are starting to emerge based on successful, enterprise-wide deployments. To follow are the 10 most common mistakes companies make when implementing an SOA project. Recognize and avoid these potential pitfalls to successfully get your SOA initiative off the ground: (1) Taking a Shotgun Approach; (2) Failing to Involve Business Analysts; (3) Spending More Time on SOA Products than SOA Planning; (4) Tackling the Largest Projects First; (5) Forgetting that SOA is a Business Problem; (6) Treating Identity as an Afterthought; (7) Buying New Products When Existing Investments Suffice; (8) Misunderstanding Company Key Players; (9) Expecting the SOA Project to Spread Quickly; (10) Lacking Necessary Elements.
Barbara Darrow, Application Development Trends
See also: Google Web Toolkit (GWT)
David Norfolk, Computer Weekly
JustSystems is offering xfy Technology as a fundamentally disruptive technology, promoted as "the world's first XML-based information delivery framework". Xfy is a data processor not a word processor and can create all sorts of standards-based documentation. It could be described as an XML browser, rather than a web browser. It deals with XML from scratch and makes use of XML Schema, Extensible Stylesheet Language Transformations (XSLT) and the extensibility of XML. xfy is a new approach to building RIA, which produces composite documents based on standard XML and integration via XSLT. It is a framework for enterprise mashups with role-based visualisation and translation—which "enables" the addition of semantics (meaning) to data (its roadmap seems to support semantic web in the future) and manages complexity. It features fast deployment, and there is no expensive XML parsing before data can be used. It is centralised and server-based. Xfy competes with Silverlight and Flex, but it is just about XML, not code - it is "just" an RIA-style framework for near-real-time applications. It is most effective in (but not limited to) Java environment, as xfy has a Java-based client that can combine/unify/normalise and visualise information from multiple sources on the client side without the need for server-based scripting. Debuggers are available but everything is built from reusable XML components, so xfy users should not get into deep, complicated programming-style logic...
I've been reviewing the Access Control for Cross-site Requests document. One interesting aspect of the document is that it specifies how a web site can authorize other web sites to do non-GET operations such as PUT or DELETE. The client makes an authorization request by creating an HTTP GET with the http header Method-Check. The server then responds with an HTTP Response containing Access-Control HTTP Headers or even an XML document with Processing Instructions. The part that I found very interesting is that it seems that the client's authorization request isn't really for the resource identified by the URI, because the goal is to actually get the authorization information. Thus, an HTTP GET has been over-ridden to be a GET of metadata about a resource. Also interestingly, if the URI for some reason doesn't know about the Method-Check header, then it will return the "wrong" representation, that is the actual representation. There is no way of requiring that the server knows about the Method-Check request. Over in WS-* land, WS-ResourceTransfer is a specification that uses a SOAP header wsrt:ResourceTransfer to indicate that there may be RT specific extensions to the WS-Transfer operation, such as GET. Because it uses a SOAP header, it can use the soap:mustUnderstand attribute to require that the server understand it. Seems to me like this is an interesting case of where SOAP solves a problem that the Access Control for Cross-site requests has, that is the ability to mark a header as mustUnderstand. This isn't surprising, given that SOAP was exactly created to solve problems with HTTP headers.
See also: Access Control for Cross-site Requests
A Uniform Resource Name (URN) for Emergency and Other Well-Known Services
Henning Schulzrinne (ed), IETF Internet Draft
The IETF RFC Editor Team announced the publication of a new RFC in the online RFC libraries. Standards Track RFC 5131 ("A Uniform Resource Name (URN) for Emergency and Other Well-Known Services") was produced by members of the IETF Emergency Context Resolution with Internet Technologies (ECRIT) Working Group. This is now a Proposed Standard Protocol in the RFC editor Queue: it specifies an Internet standards track protocol for the Internet community, and the RFC Editor Team requests discussion and suggestions for improvements. This memo describes a 'service' URN that allows well-known context-dependent services that can be resolved in a distributed manner to be identified. In existing telecommunications systems, there are many well-known communication and information services that are offered by loosely coordinated entities across a large geographic region, with well-known identifiers. Some of the services are operated by governments or regulated monopolies, others by competing commercial enterprises. Examples include emergency services (reached by dialing 9-1-1 in North America, 1-1-2 in Europe), community services and volunteer opportunities (2-1-1 in some regions of the United States), telephone directory and repair services (4-1-1 and 6-1-1 in the United States and Canada), government information services (3-1-1 in some cities in the United States), etc. Unfortunately, almost all of them are limited in scope to a single country or possibly a group of countries, such as those belonging to the North American Numbering Plan or the European Union. The same identifiers are often used for other purposes outside that region, making access to such services difficult when users travel or use devices produced outside their home country. In this document, we propose a URN namespace that, together with resolution protocols beyond the scope of this document, allows us to define such global, well-known services, while distributing the actual implementation across a large number of service-providing entities. There are many ways to divide provision of such services, such as dividing responsibility by geographic region or by the service provider a user chooses. In addition, users can choose different mapping service providers that in turn manage how geographic locations are mapped to service providers."
See also: the Emergency Services Web
The Design Goals of XML
Rick Jelliffe, O'Reilly Articles
Recently, I have heard several times people quoting the XML goals to support various opinions on what makes a good or bad markup language (schema). In particular, [the XML Specification] goal #10 Terseness is of minimal importance gets used to claim that abbreviated element names go against the spirit of XML —a blithe spirit indeed. But if we look at the XML Spec, we see that these are not general goals for XML documents to follow, but goals for the committee designing XML the technology: they are explicitly design goals... Looking at the goals [and see Tim Bray's comments in the Annotated Version of the XML spec] you can see that most of the goals are specific responses to problems either with SGML or with the SGML process at ISO then. ISO standards were supposed to have 10 year reviews which would be an opportunity for changes to be addressed, outside the ordinary maintenance process. But some influential and vital members of the ISO group had been committed to keeping SGML unchanged for as long as possible, and many of the other members who wanted change wanted changes that would support technologies such as ISO HyTime better: these would be changes that made SGML more complicated and varigated rather than simpler, to the frustration of all... [John Cowan replies:] Two failures of the XML process: It would have been better to require that public identifiers be URIs, thus allowing system identifiers to continue their historic function of being local addresses for things. Instead, we have public ids limited to the charset of formal public ids, but nobody uses (or knows how to use) FPIs. The XML Recommendation should have made clear that the purpose of attributes of type NOTATION was to specify the data type of the content of an element, rather than allowing this function to be reinvented as 'xsi:type'...
Study: Open Document Format Made Gains in 2007
Chris Kanaracus, InfoWorld
The Open Document Format saw a marked uptick in use last year across the globe, according to the ODF Alliance's 2007 report. Twelve countries and six regional governments have adopted "pro-ODF policies," according to the group, composed of companies and organizations that advocate for the format. The latest countries are the Netherlands and South Africa, which require government agencies to use the format. Also, more than 40 applications now support ODF, and the Alliance's membership ranks are set to rise above 500, according to the report. "Considering where we started when we launched the alliance back in 2006, the developments in 2007 are amazing in terms of the progress that has been made," said Marino Marcich, managing director of the group. "It's one thing to recognize ODF as a matter of policy in an enterprise architecture framework and another to mandate its use," he added. "Proprietary formats in the public sphere are going out of style and becoming unacceptable globally." The ODF Alliance's report marks another chapter in the long-brewing debate over Microsoft's Office Open XML document format and ODF, which is supported by the likes of Sun Microsystems' StarOffice application suite and Google's hosted productivity software.
See also: the OASIS OpenDocument TC
XML Daily Newslink and Cover Pages are sponsored by:
|BEA Systems, Inc.||http://www.bea.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: firstname.lastname@example.org
Newsletter unsubscribe: email@example.com
Newsletter help: firstname.lastname@example.org
Cover Pages: http://xml.coverpages.org/