This issue of XML Daily Newslink is sponsored by:
- Bibliographic Ontology Specification Leverages RDF and OWL
- Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information
- Test Cases for C14N 1.1 and XMLDSig Interoperability
- Teaching XSLT vs. Teaching XQuery
- First Look: OpenOffice.org 3.0 Public Beta
- Using Snort: Secure and Analyze Your Web Site and Its Traffic
Bibliographic Ontology Specification Leverages RDF and OWL
Frederick Giasson and Bruce D'Arcus (eds), Public Specification Document
A Revision 1.00 (2008/06/03) release of a "Bibliographic Ontology Specification" has been published as the first stable release of a new ontology of concepts and properties for describing citations and bibliographic references (i.e., quotes, books, articles, etc.) on the Semantic Web. The Bibliographic Ontology is an effort of ZitGist LLC, Bruce D'Arcus, and Zotero to express citations and bibliographic relations using RDF and to query that same information using the SPARQL query language for RDF. The intent has been to reuse many existing ontologies (formally or informally), including The Event Ontology, Address Ontology, Dublin Core Element Refinements and Encoding Schemes, Friend of a Friend (FOAF) Vocabulary, Programmes Ontology, and the Geo Ontology. The Bibliographic Ontology depends heavily on W3C's standards work, specifically on XML, XML Namespaces, RDF, and OWL. All the Bibliographic Ontology documents must be well-formed RDF/XML documents. The IFLA Functional Requirements for Bibliographic Records (FRBR) serves as the basement of the ontology. This specification contributes an ontology, the "Bibliographic Ontology ", to the Semantic Web, specifying it using W3C's Resource Description Framework (RDF). As such, the Bibliographic Ontology adopts by reference both a syntax (using XML), a data model (RDF graphs) and a mathematically grounded definition for the rules that underpin the RDF design. RDF provides the Bibliographic Ontology with a way to mix together different descriptive vocabularies in a consistent way. Vocabularies can be created by different communities and groups as appropriate and mixed together as required, without needing any centralized agreement on how terms from different vocabularies can be written down in XML or N3. The visual layout and structure of the specification was adapted from the FOAF Vocabulary Specification by Dan Brickley and Libby Miller, and from the SIOC Ontology Specification by Uldis Bojar and John G. Breslin. Yves Raimond created a new and enhanced document generator called OntoSpec used to generate the document itself.
See also: the introductory blog article
Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information
Mikko Lonnfors (et al., eds), IETF Proposed Standard
The Internet Engineering Steering Group (IESG) has approved a collection of four documents at the level of IETF Proposed Standard, all produced by members of the IETF SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Working Group. The IETF Working Group supports the advancement of these specifications, and in fact much protocol work inside and outside the IETF relies on this. This document set provides a new capability for SIMPLE: partial publications and notifications. Partial publications and notifications are updates to previous transmitted presence documents which omit redundant information, thereby saving bandwidth and processing. Both of these rely on a common partial presence document format, 'application/pidf-diff+xml'. These diffs are applied to existing presence documents through the patching technique described in the xml-patch-ops document. The documents include: (1) "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors"; (2) "Presence Information Data format (PIDF) Extension for Partial Presence"; (3) "Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information"; (4) "Publication of Partial Presence Information." The PROTO shepherd is Robert Sparks; the documents were reviewed for the IESG by Jon Peterson. Apps Area review of the XML-patch-ops document was provided by Dave Crocker, and Gen-ART review of XMLpatch-ops was provided by Joel Halpern. As described in the "Partial Notification" document: A presence event package for Session Initiation Protocol (SIP) allow users ('watchers') to subscribe to other users' ('presentities') presence information. The presence information is composed of multiple pieces of data that are delivered to the watcher. The size of the presence information document can be large (i.e., the presence document can contain an arbitrary number of elements called presence tuples that convey data). As specified in RFC 2778 and the presence event package for SIP, a Presence Agent (PA) always delivers in presence notifications all the presence data that has been authorized for a certain watcher. This is done regardless of what presence data has changed compared to last notification. It may not be reasonable to send the complete presence information over low bandwidth and high latency links when only part of the presence information has actually changed... A partial notification approach [is useful] where the presence server delivers to the watchers only those parts of the presence information that have changed compared to the presence information sent in the previous notifications. This reduces the amount of data that is transported over the network... The presence service normally operates so that a watcher sends a SIP SUBSCRIBE request targeted to the presentity. The request is routed to the presence agent where the presentity's presence information is stored. The SUBSCRIBE request can include an Accept header field that indicates the supported content types. The presence agent receives the SUBSCRIBE request and if there is no Accept header indicating the supported content types or the Accept header contains the default PIDF content type, the PA will generate presence notifications using the default PIDF format. The PIDF document can contain one or multiple XML elements. The PIDF document include a set of elements defined in RFC 2778 and its extensions for representing the presence information."
See also: XML Patch Operations Framework
Test Cases for C14N 1.1 and XMLDSig Interoperability
J-C. Cruellas, K. Lanz, S. Mullan (eds), W3C Working Group Note
Members of the W3C XML Security Specifications Maintenance Working Group (now: XML Security Working Group) published a Working Group Note "Test Cases for C14N 1.1 and XMLDSig Interoperability." The document defines interoperability test cases for Canonical XML 1.1 and XML Signature Syntax and Processing, Second Edition. The changes tested include C14N11 handling of attributes in the XML namespace, including xml:id and xml:base, appropriate C14N11 nodeset to octet stream transform processing, modifications to RFC 3986 dot segment processing for C14N11, and RFC 4514 string encoding of Distinguished Names. The tests include standalone C14N11 tests as well as tests integrated with XML signature generation and validation. This document also includes earlier test cases used in XML Signature for regression testing. The set of test cases documented in this report was used to provide evidence for implementation support for the Canonical XML 1.1 and XML Signature Proposed (Edited) Recommendations. While the Working Group might publish revised versions of this document to include mild improvements of the test documentation, there is no expectation that the core material in this document will change. It should be noted that no material in this document is normative; in particular, passing the tests documented in this document is neither necessary, nor sufficient for a conformance claim against either Canonical XML 1.1 or XML Signature Second Edition. Major contributions to this document were received from Juan Carlos Cruellas, UPC; Konrad Lanz, A-SIT; Sean Mullan, Sun Microsystems; Pratik Datta, Oracle; Frederick Hirsch, Nokia; Bruce Rich, IBM; Thomas Roessler, W3C.
See also: the W3C XML Security Working Group
Teaching XSLT vs. Teaching XQuery
Dan McCreary, O'Reilly Opinion
Is it easier to teach XSLT or XQuery to an experienced SQL developer? For the last six years I have been building metadata management systems using a diverse set of XML-centric technologies. These languages include XML Schemas, XSLT, Schematron, XHTML, XForms and most recently XQuery. And to be honest, I really do enjoy XQuery. My job as a consultant is to develop feature-rich and highly customizable metadata management systems for my customers and also transfer the skills needed to maintain and extend these systems to my customers though formal training classes as well as one-on-one mentorship. I have found that it has been very difficult to teach XSLT to an average support person that is only doing occasional XSLT development. But teaching XQuery has been much easier for me to teach when you consider that most of my students have had some exposure to SQL. Looking back on my own learning process, I recall took me about five months of almost continuous study to really feel comfortable with XSLT. Most of this learning curve was because I had not done production XSLT development. But I picked up XQuery in just a few weeks. Perhaps this is because I was already familiar with SQL and XPath. But perhaps this is because XQuery is a little bit more approachable. I want to note that this does not necessarily imply a poor design of XSLT or the merits of functional programming. After I did learn XSLT I became a real evangelist of its elegance and beauty. At first I was frustrated by not being able to change a 'variable'. Later I realized that this restriction is what made XSLT beautiful, simple and elegant. These features keep the transforms free of side-effects. Once XSLT scripts are deployed I seldom found problems. I became enthralled by the fact that the simplicity of the language implied that XSLT custom-hardware could allow transforms to be orders of magnitudes faster than software-only solutions. XSLT may always have a place in CPU-intensive applications. The difference in my learning time and those of my students reflects the state of our existing knowledge base: most of are already familiar with SQL. Anyone that knows SQL can take a crash course in XQuery designed specifically for SQL developers...
First Look: OpenOffice.org 3.0 Public Beta
Will Kraft, Application Development Trends
"A new beta version of OpenOffice.org was released last month. I've used the OpenOffice.org productivity suite almost exclusively over the past few years for producing documents, and it has always done what I've needed it to. I've seen it grow from its version 1.x days to become a serious competitor to Microsoft Office, and the new OpenOffice.org 3.0 beta (OO3) continues that trend. I tested the Windows beta, since that is the version that people are most likely to use. During the duration of the test, OO3 was very stable and fully functional. I did not experience any crashes or other problems. It's a beta, though, and OpenOffice.org's backer, Sun Microsystems, encourages general use of the current stable version (2.4) for production work. The most significant new feature in OO3 is a native Mac OS X version with full Aqua integration, which eliminates the prior dependence on X11 and the primary need for OpenOffice.org derivatives like NeoOffice. NeoOffice has traditionally stayed ahead of the feature curve, so it will be interesting to see what the future holds for it. Another notable feature is the inclusion of converters meant to handle the document formats used with Office 2007 applications... The OO3 beta includes application improvements. Writer (the word processing module) has upgraded editing features, allowing the user to track changes on several pages of a document at once. In addition, a more powerful and intuitive note system (with colors varying by user/editor) has replaced the cumbersome yellow note boxes in previous versions. Calc (the spreadsheet module) has a new solver feature, which is meant to aid in optimization calculations while taking constraints from other cells into consideration. Also, OO3 supports much larger spreadsheets. For instance, column support has been increased to 1,024 from the prior limit of 256 columns. Charting has been upgraded to allow error bars and regression equations..."
See also: OpenOffice.org 3.0 Beta Features
Using Snort: Secure and Analyze Your Web Site and Its Traffic
Brett D. McLaughlin, IBM developerWorks
Snort is a free and open source Network Intrusion Prevention System (NIPS) and Network Intrusion Detection System (NIDS) tool for managing and preventing intrusions to your Web sites, applications, and Internet-enabled programs. Intrusion detection is recognizing an unexpected access to a network; the access could be as simple as a Web page being accessed improperly —perhaps a secured admin form or shell access to the entire root directory of a Web site. On the other hand, an intrusion can be very sophisticated, such as changing DNS tables so that requests to one site all get redirected to another, hacker-controlled domain or replacing the .htaccess file on an Apache Web server with a more permissive one, allowing a hacker to add, remove, and change user information, including passwords. The detection part, of course, is all about recognizing—and then preventing -- this sort of thing from happening. So when it comes to a tool or system that focuses on intrusion detection, you're talking about anything from a high-end professional firewall from Cisco to a simple Snort installation. Because not many organizations can drop tens and even hundreds of thousands of dollars into high-end hardware, an open source application like Snort is perfect for getting basic intrusion detection running with minimal expenses and hassles.
See also: the Snort web site
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/