|
|
|
 |
<< Monday, October 20, 2003 >> |
|
W3C vs. OASIS patent policies
At last week's Digital ID conference, Phil Windley gave an excellent overview of a number of base technologies, including SAML and XACML, two OASIS standards. Cory Doctorow suggested that these are OASIS rather than W3C standards because the OASIS patent policy doesn't encourage patent disclosure and royalty-free licensing as vigorously as the W3C patent policy now does.
Phil didn't have an immediate answer and, after rereading the two policies, neither do I. They are superficially similar but, of course, I am not a lawyer. I do note that, in the case of XACML, approval was delayed -- according to OASIS' Karl Best -- until the technical committee convinced itself that there wasn't going to be a patent hitch:
The XACML TC has taken reasonable steps to ensure and to document that all features of this language are derived from previous work in the field that is not under patent restrictions. We intentionally made one feature of the language - Obligations - not mandatory to implement in order to make it easier for implementations to avoid a particular feature that might, in some cases, infringe on a known IP claim.
It is the belief of the TC that useful and fully-compliant implementations of XACML 1.0 can be created that are royalty free. The TC therefore requests that OASIS adopt the XACML 1.0 specification as submitted." [OASIS xacml mailing list]
Still, Cory raises an interesting point. I haven't seen a side-by-side legal analysis of the W3C and OASIS policies, nor of the motivations vendors have for aligning with one or the other. Comments and pointers are welcome.
|
|
GUIs, linking, and interface experimentation
In one crucial way, the rich GUI is tragically disadvantaged with respect to its poor browser cousin. Trying to sort out a permissions problem with IIS 6, I clicked a Help button and landed on a Web page. The page could only describe the tree-navigation procedure required to find the tabbed dialog box where I could address the problem. It could not link to that dialog box. This is nuts when you stop and think about it. Documentation of GUI software needs pages of screenshots and text to describe procedures that, on the Web, are encapsulated in links that can be published, bookmarked, and e-mailed. A GUI that doesn't embrace linking can never be truly rich. [InfoWorld: How rich is the rich GUI?: October 17, 2003]
Everybody agreed with the central theme of this column: the "rich" GUI ought to embrace linking. The secondary theme -- that the "rich" GUI ought to be richer on its own terms -- provoked a variety of responses. Danny Ayers worked up an interesting CSS/JavaScript variant of Samuel Wan's fisheye demo. Hamish Harvey's response:
I may be wrong, but it seems to me that the CSS provides a pretty effect, whereas the Flash version provides a genuinely different (though I'm not yet sure if it's useful) way to deal with long lists in short spaces. [MishMash]
Actually, I thought the CSS variant was cool, and could probably mimic the Flash technique more closely if needed. Like Hamish, I'm not sure this is a useful technique, but I mentioned it in the column just because it's striking how little UI innovation there is. Len Bullard wrote to second that observation:
To improve the GUI, we don't need more dancing
tabs, we need richer integration metaphors. Can
we get those without creating domain-focused,
limitations? In other words, going from GUIs
that anyone can use to GUIs that only specialists
can use somewhat following the evolution path
of domain languages? Is that progress?
Should we look more carefully at the intersections
of 3D virtual characters and RPGs as means to find
and present information, faces on the agents? Should
we work harder at understanding the relationships among
the sign systems that people use in daily life and
the effects these have on human emotions?
Most of what we do with GUIs, trees, tabs, dropdowns,
cascading menus and so on, is list process named items.
A richer interface would be conversational and would
organize itself dynamically according to its role.
Len asks great questions, and we won't be able to answer them until we do the experiments. Oddly, there doesn't seem to be much experimentation going on.
Update: J. Scott Anderson wrote to say:
I found it interesting that you mention the fisheye effect yet failed
to mention the effect in active everyday use -- the Macintosh OS X Dock.
In my opinion, there is a very successful implementation of such an
effect.
Good point. I use OS X myself, and should have made that connection. Thanks!
|
|
|
Recent Entries
|
|
NEWS 
