xhtml
Submitted by administrator on Sat, 05/17/2008 - 19:12.
Something which was part of the early design concepts from the XHTML Role Attribute Module, which has got a little lost, is that elements from any language can provide a handy source of role values too.
To reconstruct the logic:
A role value is simply a URI, or resource. The reason for this is so that the extensibility hook that we're creating puts us straight into the world of RDF.
Now, some values of @role will need to be invented. This might be because they simply don't exist, or because we want the values to be 'cross-cutting', and apply to many different mark-up languages.
But there are many values that already exist, that are suitable for use in a variety of situations. For example, XForms has a hint element, that can apply to its form controls:
<xf:input ref="surname">
<xf:label>Surname:</xf:label>
<xf:hint>Please enter your surname or family name</xf:hint>
</xf:input> The semantics of 'XForms hint' and pretty well defined, so it should be straightforward to apply them to other situations. For example, an Ajax library could pick up a hint and do something with it in an (X)HTML document, even without XForms:
<input name="surname" />
<div role="xf:hint">
Please enter your name
</div> SVG
This whole topic came up recently because someone asked whether it would be possible to add some new values for role which would identify paragraphs, sections, headers, and so on, and that could e used in languages like SVG; but the answer is that if we use the XHTML p, section, h1, h2, etc., values then we don't need to invent new roles:
<svg:text role="xh:h1">Metadata</svg:text>
<svg:text role="xh:p">
Metadata is data about data...which is also data...kind of
turtles all the way down...
</svg:text> As you can see, a role-aware voice system would be able to provide feedback to a user in any mark-up language, simply by knowing XHTML role values.
Submitted by administrator on Thu, 05/01/2008 - 12:50.
May is going to be pretty busy with talks about XForms, RDF and RDFa coming up.
First up is my talk XForms, REST, XQuery...and skimming at XTech 2008. The talk embraces themes I've been pursuing for a couple of years now; that as we put more functionality into the client, and servers get 'cleverer', it becomes much easier to build sophisticated web applications. Of course server technologies are moving so fast now that this whole approach is making more and more sense, so I'm looking forward to taking in recent developments in my talk. For example, both Amazon and Google effectively have 'databases in the cloud' that can be used to store data and query it, via APIs, with literally no configuration.
A few weeks later I'm going to be giving a tutorial on RDF at SemTech. This is an interesting development for me, because RDF and the semantic web were always my first interests--before XForms and before XHTML 2. (As well as writing RDF parsers, and designing applications, I also contributed chapters on RDF and RDFS to a couple of books on metadata and XML.)
But one problem I always had when trying to build semantic-web applications was that defining the user interface was pretty hairy. This was partly because RDF Schema is tricky to process, but also because HTML was insufficiently powerful in its core feature-set, so the translation from RDF to HTML involved a lot of work.
The need for a user interface language that was much richer than HTML was therefore why I got involved in the XForms standard (and worked with a team of people to produce the first fully conforming XForms processor, formsPlayer). So although it may not seem directly connected to the semantic web, I believe that in the coming period XForms will start to become a key part of the semantic web's architecture.
Another problem I kept coming up against whilst developing for the semantic web was the difficulty in actually publishing metadata. In particular I always found it frustrating that there was a lot of really useful metadata just sitting in ordinary web pages, and no-one could get at it. Attempting to resolve this problem gave rise to RDFa, and I'm excited that the RDFa in XHTML working draft is extremely close to becoming a stable recommendation. And as interest in RDFa grows, I'm pleased to say that some of my other presentations in May will be 'tech talks' on RDFa at Yahoo!, eBay and Google. (I'm really excited that I might be getting to meet some of the guys behind Yahoo!'s SearchMonkey.)
My final talk of the month will be at the excitingly-named Kings of Code, and I'm looking forward to talking about XHTML, XHTML 2, HTML 5, XAML, and anything else I can think of in relation to web languages.
Submitted by administrator on Wed, 01/30/2008 - 04:51.
Here is an example code for how to do multiple constraints on a form.
<?xml version=”1.0″ ?>
<?xml-stylesheet href=”xforms.css” type=”text/css”?>
<html xmlns=”http://www.w3.org/1999/xhtml”
xmlns:xf=”http://www.w3.org/2002/xforms”>
<head>
<title>Using XForms</title>
<xf:model id=”login”>
<xf:instance xmlns=”">
<verifyUser>
<userID1/>
<userID2/>
<password1/>
<password2/>
<email1/>
<email2/>
</verifyUser>
</xf:instance>
<!– This will NOT work!! (although it will work for a singlen constraint)
<xf:bind constraint=”//userID1=//userID2″ />
<xf:bind constraint=”//password1=//password2″/>
<xf:bind constraint=”//email1=//email2″/>
–>
<xf:bind nodeset=”//userID1″ constraint=”.=//userID2″/>
<xf:bind nodeset=”//password1″ constraint=”.=//password2″/>
<xf:bind nodeset=”//email1″ constraint=”.=//email2″/>
<xf:submission action=”viewsubmitdata.php” method=”post” id=”loginsubmit”/>
</xf:model>
</head>
<body>
<xf:input ref=”//userID1″ model=”login”>
<xf:label>Username1 </xf:label>
</xf:input>
<xf:input ref=”//userID2″ model=”login”>
<xf:label>Username2 </xf:label>
</xf:input>
<xf:input ref=”//password1″ [...]
Submitted by administrator on Tue, 01/08/2008 - 15:44.
Yahoo! recently announced their entry into the mobile web applications space, with a service that allows applications to be built and hosted using Blueprint, a purpose-built mark-up language based on XForms.
The Blueprint roadmap describes the underlying philosophy:
Much of Blueprint's philosophy and syntax comes from XForms. We opted for a full declarative language because it was the only way we could effectively run on the wide range of devices out there, some of which have no scripting at all. By using declarative syntax, we can encapsulate and hide the scripting specifics. In some cases, the code could run on the phone, in other case, such as XHTML, we can put the logic on our servers. It's the perfect way to deal with the various environments and their capabilities.
At the moment Blueprint is simply converted to XHTML plus JavaScript for delivery to devices, but the mention of XForms gives a clear indication of where they are heading. And given that Google did something similar with the launch of its Google Mashup Language, it all bodes well for a new wave of web applications that won't be built using JavaScript (or even Java and GWT) but will use straightforward, device-independent, mark-up.
Write once, run anywhere, anybody?
For more on why XForms is Ajax on steroids, see:
Submitted by administrator on Tue, 10/09/2007 - 21:50.
XQuery, the Server Language
An Xquery article by Kurt Cagle.
Submitted by administrator on Tue, 10/09/2007 - 20:51.
I put a toggle inside a legend simply because it just popped in my head to try it. This same procedure could work with any type of grouped data without having a legend at all (see Switch/Case Toggle Template or Using Switch Case as a drop down box).
In my post Xforms: The Legendary [...]
Submitted by administrator on Tue, 10/09/2007 - 20:23.
Anyone who has followed my blog knows that I use php to parse my xml data by simply putting my data into an indexed array or an associative array and then manipulating the data as you would any other arrayed data (see http://clarkepeters.wordpress.com/2007/09/02/parsing-without-the-dom-or-.... I’m not advocating, however, that this is the best [...]
Submitted by administrator on Wed, 09/19/2007 - 22:13.
A dropover is a drop box that is intended to drop down over any elements that are displayed below it.
For an example see Drop Down over/above lower text (Xforms Switch and CSS). In fact, you’ll need to look over that post to get an idea of what’s going on here (you may want [...]
Submitted by administrator on Sun, 09/16/2007 - 08:26.
I have an xhtml+xforms form in which users are viewing or deleting files from their server. (see earlier posts if you want to know more).
The file names are stored in an xml instance that the xforms is based on. The file names are listed as items in an xf:select1 control (actually in this case, it’s [...]
Submitted by administrator on Thu, 09/13/2007 - 12:01.
Here are some images that show how the Switch/Case Toggle works (see Switch/Case Toggle Template ) . In this particular example, notice how the box drops down above the division below it rather then pushing that division down (which is how it normally operates without any CSS styling). [...]
Submitted by administrator on Tue, 09/11/2007 - 20:23.
In an earlier post– don’t hit the back arrow! — I was using Xforms to prevent loss of recent data from a browsers back button or browser reload page, in which case the user would be directed to an interim page that had some instructions about navigating the site and also a button where they [...]
Submitted by administrator on Tue, 08/28/2007 - 19:23.
A couple of recent discussions in the RDFa and microformat communities concern areas of particular interest to those of us working on Sidewinder, a semantic web applications framework.
The initial discussion is taking place on the microformats lists, and concerns how to allow authors to indicate what actions are available to be performed on items appearing in a document. The second discussion is taking place on the 'RDF in XHTML Task Force' list; this post provides a good summary of some of the issues.
All in all I find these very exciting discussions, because they concern exactly the types of use-case that prompted me to get involved with the XHTML work at the W3C a number of years ago.
This was because I'd been trying to create the kind of flexible user interface that these threads are describing--no doubt just as lots of other people had--and in my own endeavours I ran up against a number of very serious problems that made me conclude that it was pretty much impossible with the technologies available at the time. And since I still haven't seen a convincing solution to the problem of creating extremely flexible user interfaces, I've concluded that the issues I ran up against are of quite a fundamental nature.
Some of the problems that seem to me to be absolutely necessary to solve are:
- an HTML page contains insufficient metadata about what its content 'means', making it difficult to work out what kind of UI constructs to render;
- even were you are able to work out what the data means, HTML is not itself powerful enough to express the kinds of complex user interfaces that you would want to 'bind' to this underlying data;
- and even if you work out what the data means and define complex UI components, you still can't define binding rules that indicate what widget to use with what data;
- the browser offers only one 'paradigm' for interacting with information of interest, whilst we often want to create applications that can make use of the same rich features.
For every problem...
The first problem--that HTML is not 'rich' enough--is now largely solved by RDFa. It has taken quite a long time to get here, but I think the effort that has gone into getting RDFa right is going to be worth it. The key thing that RDFa does is to get RDF into HTML--once you've got that, all sorts of possibilities open up.
The second problem--that it's difficult to define rich user interfaces with only HTML--is largely solved by XForms. That XForms is a solution is currently not obvious to most people so XForms remains peripheral in application development at the moment. Of course it is possible to define widgets using script but it quickly gets very messy. There is also an enormous problem of re-use, in the recursive sense; most Ajax libraries are works of art, but very few can support the kind of complexity we need. Take the example shown here:
Here we have widgets that are made up of other widgets to an arbitrary depth, but the key thing is that the binding mechanism is based on abstractions; it could be the run-time data type or an abstract widget type, and in both cases it means that at any point in the hierarchy a different widget could be swapped in without disturbing anything above or below. This kind of complexity is extremely difficult to achieve with procedural languages. (See also Introduction to custom controls and Understanding the MVC separation.)
The third problem--the use of binding rules to indicate which widget should be connected to what data--is still a little in the air. One part of it we've solved by specifying binding 'rules' using XPath selectors that are data type aware. This means that we can indicate that data of type 'geo location' should have one set of behaviour bound to it, whilst data of type 'time' can have a different type. These are essentially binding stylesheets and I think this is where we can answer the question posed on the RDFa list as to whether it is the author, the end-user or the browser vendor that should be in control of the widgets--the answer is all of them! By allowing users to express binding rules that override those from authors, we can achieve the best of both worlds.
Finally, the problem that the only paradigm we have for interacting with web-based data is 'browsing' is what we are trying to solve with Sidewinder. The ultimate goal is to have a framework that can be used to build any type of internet-facing application, whether web or desktop based. By allowing all applications to make use of the same semantic functionality and the same binding rules we can allow the users themselves to get control of their data and their applications. (See also Web 2.0, Copernicus and Sparticus: Moving the centre of the web.)
Once you have this kind of 'platform' (see Platform 2.0) then things really start to open up. I could build a clock widget using Silverlight, perhaps, and have that appear anywhere that the time data type is used--whether in my messaging client, my email client, my Twitter gadget, my Facebook desktop notification system, and so on. But you might choose a clock built using SVG, whilst someone else might decide to have a clock that speaks. But any of us could swap one of these behaviours for another at will, for a component we have created or one that we have downloaded from elsewhere--the ultimate, flexible, programming platform.
Submitted by administrator on Wed, 08/22/2007 - 08:42.
The XHTML.com site have published the first part of a two part series on what might be wrong with the web, and how we might fix it. The idea is that the first part consists of short opinion pieces by people involved in various ways with the web, and the second part is a collection of responses from anyone who wants to send something in.
Contributors are Chris Wilson, Daniel Glazman, Joe Clark, Doug Geoffray, Roberto Scano, Jeffrey Veen, Dave Raggett, Mike Andrews, James Pearce, Nova Spivack and myself.
In my comments I focused on the need for a better way to create standards:
I actually have a very positive view of the transition to the 'future Web', and I see many of the things that one might say we need for a better Web already emerging. For example, we need the differences between browsers to be removed, but due to the high quality of libraries such as YUI, Dojo, and Prototype this is well underway. We also need there to be a convergence of application development techniques, so that the same languages can be used for the Web, desktop applications, gadgets, widgets, and so on; but with an explosion of interest in HTML, JavaScript and XForms--as well as the appearance of multi-language platforms like Silverlight--this trend also looks set to continue.
So whilst I might say that these things are crucial to the future of the Web, they are also very much underway, and barring a collective overnight loss of memory by the development community, look certain to continue. But there is one thing that to me doesn't look so assured, and that is whether standards are agreed upon around Ajax, and more generally, the whole approach to standards development.
In general, standards (at least those from the W3C) are developed in a kind of 'kitchen-sink' style, where some specification tries to include just about everything that can be devised on a particular topic--and therefore takes years to write. A good example is SVG, and even, to some extent, my own favourite, XForms. In both cases there are many useful things that could be factored out of these specifications to be made available elsewhere as smaller, more manageable components, but it is only recently that this approach has started to be tried. Good examples of the 'bite-size' approach are the 'role attribute', 'access', and RDFa, which provide techniques for adding metadata to web documents as well as making them more accessible. (See also The XHTML role attribute: small and perfectly formed and Using RDFa in XHTML 1.)
A good measure that some are learning that this is a promising approach to writing specifications is the backplane initiative at the W3C. But unfortunately, an illustration that lessons haven't been learned is the W3C's embracing of HTML 5, which is not only a case study in kitchen-sink design--let's throw everything in there--but a case study too of the problems caused by the 'not invented here' mindset.
If the W3C continues to support the creation of enormous specifications that take years rather than months to complete, then it will almost certainly become increasingly irrelevant to the 'future Web'. Of course, based on the W3C's lack of coherent leadership around the whole HTML 5 question, some might not see that as necessarily a bad thing, but it does raise the question as to whether other organisations can fill the space with a better process. For example, can the Open Ajax Alliance take a much more focused approach to standards writing, creating small specifications that can be easily combined? If so, it's possible that the vacuum would be filled, and the future of the 'future Web' would stand on a firmer footing.
Whilst I'm not quite sure where the future of standards creation will come from, the sheer dynamism we see in the Web development space makes me certain that it is imminent. If we can devote even a fraction of that creative energy to evolving a new approach to standards development, the future of the 'future Web' looks very bright indeed. But if we don't, then for the foreseeable future we are looking at increasing fragmentation, and the lack of standardisation in the browser merely being transferred to a 'lack of standardisation in the libraries'.
Anyone is free to respond to the discussion, which needs to be done by September 10th. They'll then use the responses to create 'part 2'.
|
