RDFa APIAn API for extracting structured data from Web documentsW3C Working Draft 08 June 2010
3More
RDFa API - 0 views
-
RDFa [RDFA-CORE] enables authors to publish structured information that is both human- and machine-readable. Concepts that have traditionally been difficult for machines to detect, like people, places, events, music, movies, and recipes, are now easily marked up in Web documents. While publishing this data is vital to the growth of Linked Data, using the information to improve the collective utility of the Web for humankind is the true goal. To accomplish this goal, it must be simple for Web developers to extract and utilize structured information from a Web document. This document details such a mechanism; an RDFa Document Object Model Application Programming Interface (RDFa DOM API) that allows simple extraction and usage of structured information from a Web document.
-
This document is a detailed specification for an RDFa DOM API. The document is primarily intended for the following audiences: User Agent developers that are providing a mechanism to programatically extract RDF Triples from RDFa in a host language such as XHTML+RDFa [XHTML-RDFA], HTML+RDFa [HTML-RDFA] or SVG Tiny 1.2 [SVGTINY12], DOM tool developers that want to provide a mechanism for extracting RDFa content via programming languages such as JavaScript, Python, Ruby, or Perl, and Developers that want to understand the inner workings and design criteria for the RDFa DOM API.
2More
ODF Plugfest: Making office tools interoperable [LWN.net] - 0 views
-
ODF on the web An especially interesting project that was presented is WebODF, which wants to bring ODF to the web. Jos van den Oever started from the observation that a lot of office suites are moving into the "cloud". Examples are Microsoft Live Office, Google Docs, and Zoho. But where are the free software alternatives for the cloud? For OpenOffice.org, KOffice, AbiWord, and Gnumeric, there are none that have a cloud version with ODF support. That was the motivation for Jos to start a project to fill in this gap and let users view and edit ODF documents on the web without losing control of the document into some company's servers. The strategy Jos followed was to use just HTML and JavaScript for the web application. The application then loads the XML stream of the ODF document as is into the HTML document and puts it into the DOM tree. Styling is done by applying CSS rules that are directly derived from the <office:styles> and <office:automatic-styles> elements in the ODF document. That is how WebODF was born; it is a project with the initial goal of creating a simple ODF viewer and editor for offline and online use, implemented in HTML5. The small code base consists of one HTML5 file and eight JavaScript files, each of which is a few hundred lines of code. The most interesting part is that it doesn't need server-side code execution: the JavaScript code is executed in the user's browser and saving the document to the web server is done using WebDAV. It supports both the Gecko and WebKit HTML engines. There is also an implementation on top of QtWebKit, which is for better desktop integration, and an ODFKit implementation. This means that WebODF is an easy way to add ODF support to almost any application, be it in HTML, Gtk, or QML. KO GmbH has received funding from NLnet to improve the current WebODF prototype and see how far the idea goes. Interested readers can try the online demo.
-
Notification of this article also appeared in the Diigo Document Wars Group..... WebODF... An especially interesting project that was presented is WebODF, which wants to bring ODF to the web. Jos van den Oever started from the observation that a lot of office suites are moving into the "cloud". Examples are Microsoft Live Office, Google Docs, and Zoho. But where are the free software alternatives for the cloud? For OpenOffice.org, KOffice, AbiWord, and Gnumeric, there are none that have a cloud version with ODF support. That was the motivation for Jos to start a project to fill in this gap and let users view and edit ODF documents on the web without losing control of the document into some company's servers. The strategy Jos followed was to use just HTML and JavaScript for the web application. The application then loads the XML stream of the ODF document as is into the HTML document and puts it into the DOM tree. Styling is done by applying CSS rules that are directly derived from the and elements in the ODF document. That is how WebODF was born; it is a project with the initial goal of creating a simple ODF viewer and editor for offline and online use, implemented in HTML5. The small code base consists of one HTML5 file and eight JavaScript files, each of which is a few hundred lines of code. The most interesting part is that it doesn't need server-side code execution: the JavaScript code is executed in the user's browser and saving the document to the web server is done using WebDAV. It supports both the Gecko and WebKit HTML engines. There is also an implementation on top of QtWebKit, which is for better desktop integration, and an ODFKit implementation. This means that WebODF is an easy way to add ODF support to almost any application, be it in HTML, Gtk, or QML. KO GmbH has received funding from NLnet to improve the current WebODF prototype and see how far the idea goes. Interested readers can try the online demo
15More
shared by Gary Edwards on 07 Jun 11
- No Cached
Why a JavaScript hater thinks everyone needs to learn JavaScript in the next year - O'R... - 1 views
radar.oreilly.com/...time-to-learn-javascript.html
JavaScript HTML+ Node.JS JQuery web-apps web-application-development
![](/images/link.gif)
-
.js has the potential to revolutionize web development. It is a framework for building high performance web applications: applications that can respond very quickly and efficiently to a high volume of incoming requests.
- ...11 more annotations...
-
HTML5, then, isn't really a major advance in angle-bracket-based tagging; it's about enabling JavaScr
-
JavaScript has long been the workhorse for implementing dynamic features in HTML. But there have always been two problems: browser incompatibilities, and the awkwardness of working directly with the DOM. The JQuery library has elegantly solved both problems, and is the basis for modern client-side browser development.
-
Web servers, rich web client libraries, HTML5, databases, even JavaScript-based languages: I see JavaScript everywhere.
-
OK, this article gets my vote as the most important read of the year. We all know that the the Web is the future of both computing and communications/connectivity. But wha tis the future of the Web? Uber coder Mike Loukides says it's JavaScript, and what a compelling case he builds. This is a must read. Key concepts are diigo highlighted :) excerpt: JavaScript has "grown up." I'm sure there are many JavaScript developers who would take issue with that judgement, and argue that JavaScript has been a capable, mature, and under-appreciated language all along. They may be right, though you can write any program in any complete programming language, including awful things like BASIC. What makes a language useful is some combination of the language's expressiveness and the libraries and tools available. JavaScript clearly passed the expressiveness barrier a long time ago, even if the ceremony required for creating objects is distasteful. But recently, we've seen some extremely important game-changers: jQuery, JSON, Node.js, and HTML5. JavaScript may have been a perfectly adequate language in the past, but these changes (and a few others that I'll point out) have made JavaScript a language that is essential for every developer to know. If there's one language you need to learn in the next year, it's JavaScript. Insightful comment: HTML5 is a JavaScript API, introducing new elements but significantly redefining ALL elements as objects or classes. Elements can be expressed with tags. Or, you can use DOM JavaScripting to create elements.
1More
Shine on Silverlight and Windows with XAML * The Register : Tim Anderson - 0 views
-
Excellent explanation and review from the Tim Anderson. I wonder how i missed this? Here is the summary statement: "..... You can also extend XAML with custom objects. The main requirement is that classes used in XAML must have a parameterless constructor. The procedure is straightforward. Define a class; make sure your application has a reference to the assembly containing the class; then add a namespace declaration for the assembly. You can then define elements in XAML that map to your class, and at runtime these will become object instances. XAML has a curious story when it comes to formatted text, especially in Silverlight. In one sense it is rather limited. XAML has no understanding of common formats such as HTML, CSS or RTF, let alone the fancy new OOXML. Silverlight developers have to interact with the browser DOM in order to display HTML." "... No escaping it: Silverlight .XAP bundle preserves the original XAML. That said, XAML with WPF actually is a document format. The full WPF has an element called FlowDocument and rich formatting capabilities. Silverlight lacks FlowDocument, but does have a TextBlock with basic formatting options via the inline object. It also supports the Glyph element. This is interesting because it is the core element in XPS, Microsoft's invented-here alternative to Adobe's PDF." ".... XPS uses a subset of XAML to describe fixed layouts. In consequence, and with some compromises, you can use Silverlight to display XPS." "..... The bottom line is that XAML is a way of programming .NET declaratively. Its more intricate features improve the mapping between XAML and .NET. The result is we have design tools like Microsoft's Expression Blend and a clean separation between UI objects and program code, which is a considerable achievement." ".... As ever there's a downside, and with Microsoft it's the classic: this is thoroughly proprietary, and the schema issues make it difficult to validate with standard XML tools." No
4More
Frequently Asked Questions (FAQ) about the future of XHTML - 0 views
-
In its specifications and process, W3C seeks a balance between stability (for interoperability) and flexibility (to accommodate evolution). HTML 5 has a number of extensibility mechanisms, but none yet that satisfies the requirement XML namespaces was designed to address of decentralized extensibility - allowing parties to include their own elements or attributes in content without risk of name collisions (whether those names are the result of a consensus process or not). An HTML Working Group issue on decentralized extensibility is still open and unresolved. The text/html serialization of HTML5 contains extensibility points but does not provide a decentralized mechanism. One of the open questions is what extensibility mechanism can be used such that, when it is parsed from either the HTML or XML serialization, the DOM that results is the same (see HTML Design Principles section 3.5).
-
Work will stop on these documents (likely to be published as Group Notes): XHTML 2.0 CURIE XFrames HLink XHTML+MathML+SVG Profile XHTML Modularization 1.0 Second Edition
-
W3C plans to continue work on XForms within the Forms Working Group (see information about deployment
- ...1 more annotation...
-
As of June 2009, many parts of HTML have been written primarily for browser implementers. W3C has heard the demand from authors for a specification that addresses authors. This is still an open issue and W3C welcomes volunteers to work with the Working Group on a version for authors
1More
PhantomJS: The Power of WebKit but Without the Broswer - 0 views
-
PhantomJS gives you command-line access to the features of WebKit. According to its website: "Literally it acts like any other WebKit-based web browser, except that nothing gets displayed to the screen (thus, the term headless)." It has native support for DOM handling, CSS selector, JSON, Canvas, SVG, and JavaScript.
3More
This project aims to make '404 not found' pages a thing of the past - 0 views
-
The Internet is always changing. Sites are rising and falling, content is deleted, and bad URLs can lead to '404 Not Found' errors that are as helpful as a brick wall. A new project proposes an do away with dead 404 errors by implementing new HTML code that will help access prior versions of hyperlinked content. With any luck, that means that you’ll never have to run into a dead link again. The “404-No-More” project is backed by a formidable coalition including members from organizations like the Harvard Library Innovation Lab, Los Alamos National Laboratory, Old Dominion University, and the Berkman Center for Internet & Society. Part of the Knight News Challenge, which seeks to strengthen the Internet for free expression and innovation through a variety of initiatives, 404-No-More recently reached the semifinal stage. The project aims to cure so-called link rot, the process by which hyperlinks become useless overtime because they point to addresses that are no longer available. If implemented, websites such as Wikipedia and other reference documents would be vastly improved. The new feature would also give Web authors a way provide links that contain both archived copies of content and specific dates of reference, the sort of information that diligent readers have to hunt down on a website like Archive.org.
-
While it may sound trivial, link rot can actually have real ramifications. Nearly 50 percent of the hyperlinks in Supreme Court decisions no longer work, a 2013 study revealed. Losing footnotes and citations in landmark legal decisions can mean losing crucial information and context about the laws that govern us. The same study found that 70 percent of URLs within the Harvard Law Review and similar journals didn’t link to the originally cited information, considered a serious loss surrounding the discussion of our laws. The project’s proponents have come up with more potential uses as well. Activists fighting censorship will have an easier time combatting government takedowns, for instance. Journalists will be much more capable of researching dynamic Web pages. “If every hyperlink was annotated with a publication date, you could automatically view an archived version of the content as the author intended for you to see it,” the project’s authors explain. The ephemeral nature of the Web could no longer be used as a weapon. Roger Macdonald, a director at the Internet Archive, called the 404-No-More project “an important contribution to preservation of knowledge.”
-
The new feature would come in the form of introducing the mset attribute to the <a> element in HTML, which would allow users of the code to specify multiple dates and copies of content as an external resource. For instance, if both the date of reference and the location of a copy of targeted content is known by an author, the new code would like like this: The 404-No-More project’s goals are numerous, but the ultimate goal is to have mset become a new HTML standard for hyperlinks. “An HTML standard that incorporates archives for hyperlinks will loop in these efforts and make the Web better for everyone,” project leaders wrote, “activists, journalists, and regular ol’ everyday web users.”
3More
Google to slip SVG into Internet Explorer * The Register - 0 views
-
Microsoft might be hesitating on Scalable Vector Graphics (SVG) in Internet Explorer 8, but Google's pressing on. The search giant's engineers are building a JavaScript library to render static and dynamic SVG in Microsoft's browser. Google promised that the library, a Javascript shim, will simply drop into IE.
-
SVG has a huge presence on the web. This facet of the World Wide Web Consortium's HTML 5 spec is supported in Firefox, Safari, Opera, Chrome, and Apple's iPhone, and is used in Google Maps and Google Docs. It also topped a list of features wanted by developers in a OpenAJAX browser wish list last year.
-
There's suspicion, though, that the reason has more to do with Microsoft's internal politics, with the company wanting graphics and drawing in IE done using Silverlight instead. SVG Web is more than an answer to Microsoft's foot-dragging, however. Google has declared for HTML 5 on the web, proclaiming last week that the web programming model has "won". Support for graphics capabilities in HTML 5 should also be seen as Google's partial answer to Adobe Systems' Flash. Google has complained that Flash is not open source and its development is not driven by the community. Google said the benefit of SVG Web is that it would sit inside the DOM whereas Flash "sits on top of the web, it's not part of the web"
1More
The HTML 5 Layout Elements Rundown - 0 views
-
TML 5 is an interesting beastie. The specification was not planned; The W3C was committed to HTML 4.1 as the last word in HTML. As such, most of the requests for HTML 5 came from the HTML user community itself, largely through the advent of the Web Hypertext Application Technology Working Group (WHATWG). The push from WHATWG was strong enough to prompt the formation of a HTML 5 working group a couple of years ago. Since then, the HTML 5 working group has slowly gone through the process of taking a somewhat hand-waving specification and recasting it in W3C terms, along with all the politics that the process entails. On April 23, 2009, the HTML 5 group released the most recent draft of the specification. Overall, it represents a considerable simplification from the previous release, especially as a number of initially proposed changes to the specification have been scaled back. The group defined roles for the proposed changes elsewhere. HTML 5 is a broad specification, and consequently, dozens of distinct changes—more than a single article can reasonably cover in any detail—occurred between HTML 4 and 5. This article focuses on the HTML 5 layout elements. Subsequent articles will examine forms-related changes (which are substantial), the new media elements, and DOM-related changes.
The core issue behind my discussions with the Rocketman have to do with creating a DOM view from OpenXML and ODF documents, and then passing that view to the webkit/Chromium engine. So we weren't all that interested in cross browser support or in how IE8 handles DOM-JavaScript. Dave Ward however not only provides a good discussion about DOM-JavaScript and the importance of jQuery as a force of interoperability, he also points out that Microsoft supports jQuery - including direct support within Visual Studio!
".....Though JavaScript itself is a great programming language, the document object model (DOM) can be a web developer's worst nightmare. The DOM is a method through which browsers expose an interface allowing JavaScript code to manipulate elements, handle events, and perform other tasks related to a document within the browser. While almost every browser implements an ECMA standard version of JavaScript, their DOM implementations are inconsistent and quirky at best. In fact, if you've had bad experiences with client-side programming in the past, it's likely that the DOM was the true source of your frustrations, not JavaScript itself. This is exactly the pain point which jQuery addresses....
..... "Officially supported by Microsoft - For many Microsoft developers, this official blessing is the clincher. Not only will Microsoft begin including jQuery with Visual Studio, but it is part of the default ASP.NET MVC project template. What's more, Microsoft Product Support Services has already begun offering support for jQuery."....