OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [humanmarkup-comment] Re: XHTML,XForms and UIML (was: Re: [uiml-discuss] RE: founding member)


Thanks Manos,

I want to interject one further wrinkle in this entire cosmos of 
considerations regarding User Interfaces, and that is 3D.

First, in theatrical terms, the current stage of 
consistently-formatted-information-delivery on the web:

In the context of the Web Services, in OASIS we have Web Services for 
Interactive Applications, Web Services for Remote Portal and Web 
Services Security. In the initial start-up phase of the first listed 
TC, one major consideration was the adoption of a 
Model-View-Controller Architecture that not only separates data and 
presentation, but also allows for a single, consistent, design-time 
operation which  is rapidly being lost in the process of fitting WSIA 
into WSRP to accommodate JSR 168 and the most elementary level of Web 
Services. The M-V-C also allows for a fairly easily understood 
administrative EDIT mode for intermediary service delivery agencies 
such as portals, but that is being lost as well.

However, after almost ten months, the initial joint interfaces 
(WSRP-WSIA) spec is now approximately 1.5MB with 100 outstanding 
issues to be decided. That is only barely overstating the case since 
some issues will be retired soon some are editorial and with the WSDL 
material deleted, the spec is slightly less than 1Meg, but does not 
include the use cases from which it was derived nor the scenarios on 
which the use cases were built.

The point is that even the simplest level is rapidly getting out of 
hand, before we even begin to use-test in the real world of the web. 
Perhaps there is something analogous to Moore's Law for the 
complexity of web standards?

One of the reasons I signed on to WSIA in the first place was to 
coordinate HumanMarkup with it. The reason for that is that 
HumanMarkup (as a standard for describing human behavior in 
communication contexts) is necessary for driving 3D humanoid avatars 
in a consistent way in 3D web environments, for my personal 
interests. However, the facts are that HumanMarkup (or something much 
like it) will be needed for adding contextual depth to simple (like 
the the first version of the WSRP-WSIA Interface Spec is simple?) 
single-sign-on authentication and preferential end-user information 
for industry purposes, and to safeguard individual human personal 
information rights for the end-users. THAT is imminently important, 
so that will get done first despite what I might prefer.

There is much more to all of this than my personal concerns, but I am 
watching as those concerns appear less and less likely to be 
susceptible of achievement. However I have not yet conceded defeat, 
though it is becoming more likely.

Back to 3D:

In the MVC architecture it would be possible for me to fairly easily, 
even using portlets, to strip out the 2D markup 
(presentation/display) information or convert it to 3D, depending on 
the permissions from the primary producers/suppliers of the data. 
Without it, and for which XForms is the best of the current crop of 
mechanisms available for that, I will be faced with a case-by-case 
procedure which will effectively eliminate the possibility of trying 
to do the conversion to 3D in a STANDARD way.

This will also make it more difficult to produce personally tailored 
3D based on end-user preferences which I presume I will have an 
advantage in understanding how to use given my position in the 
standards effort for that. However, the ability to simply use my own 
system and make it open source remains.

In the end, all that will count is whether the public and industry 
decide to use any particular system, be it a proprietary system like 
Microsoft et al provide, or a public standard open to competition 
from all comers, albeit the market cost restrictions to entrance into 
the market. That is why I have to keep an eye on UIML, whether it is 
widely useable or universal after all, and XForm which has the 
imprimatur of W3C, or any proprietary system, or semi-proprietary 
system, like Java.

The basic fundamental layouts available will restrict what I can do 
with 3D based simply on what is well known to the users out there. So 
whether it is XForms in MVC which is easier, or Web Services using or 
being used in UIML, is essentially a matter of indifference to me. 
Like it or not, and I don't, those basic culture and language-bound 
2D graphic layouts are already set in concrete. As boring as it is, 
no one is going to break new ground in that area, so it is just a 
question of whether my 3D contains html inside it, which is currently 
infeasible since it is not a part of the spec and would require some 
expensive intermediate process to convert the html to a rasterized 
bitmap in order to use it in a semi-real-time, streamed process, or 
my 3D is embedded in a window in an html page, which is doable now, I 
can do what I want to do, even if one hand is tied behind my back, so 
the question is who wins with the 2D User Interface standard within 
the Web Services context and how easy or difficult it will be to 
strip out or convert the 2D or to connect a personalized 3D context 
to be included like a portlet itself within the requested web 
services my users want.

Much of what Manos says here is all too well known to me since I have 
been struggling for the last month to figure out the wisest migration 
path to take with my own websites to live within the existing 
browsers and conform as much as possible to where XHTML is going. 
However, the exercise has taught me that it is a losing proposition 
to attempt to predict reliably where the web is actually going to go. 
It doesn't even take the path of least resistance as long as there is 
a profit to be made on manipulating the process in any given 
direction.

Regardless, good HumanMarkup personalization information will be 
possible, however it is used in a user interface. That's the best, 
and only thing, our little group can do.

Ciao,
Rex



At 12:02 PM +0300 10/11/02, Emmanuil Batsis (Manos) wrote:
>Hi Angel,
>
>>On Thu, Oct 10, 2002 at 02:09:53PM -0400, Angel Luis Diaz wrote:
>
>>>XForms in the context of XHTML 1.1 and XHTML 2.0 addresses what the
>>>industry needs, and given the context of the Web and XML today, there is
>>>little room for a stand-alone language like UIML.
>
>I strongly dissagree with your view of XHTML, at least from what I see above.
>The W3C has been working on (X)HTML to satisfy the following 
>goals(among others):
>
>i)   Make it an application of XML
>ii)  Make a clean (as much as possible) separation of content and presentation
>iii) Modularize it for extensibility and reusability. XHTML m12n in 
>DTD [1] and XML Schema [2] was published to satisfy this goal.
>
>XHTML does not (and simply cannot) cover every possible need. That's 
>why it opened up for anyone to use an existing module or add a new 
>one.
>
>A fine example of what XHTML cannot do is Mozilla's XUL and XBL 
>languages. The first one is a set of widjets and includes many 
>features that XHTML (or CSS) does not (or need) to have a clue 
>about. For example, the Box/Layout model in XUL is richer than 
>XHTML's.
>
>XBL is a language that allows creation of new widjets (also the 
>basis for XULs widjets), meaning elements with unique display 
>properties and programming logic/function, including custom events. 
>New elements can be made out of existing ones, while the content is 
>anonymous (the whole widjet is viewed as a single element by the 
>DOM).
>
>>>If UIML is indeed to be
>>>an XML module for authoring user interfaces, then to succeed it will have
>>>to be integrated into XHTML,
>
>Absolutelly; one of UIML's major applicability can be within XHTML 
>integration.
>
>>>  and given that XHTML WG has committed to
>>>integrate XForms as the forms module for XHTML2, it's difficult to
>>>understand why we need to start a separate UIML thread in Oasis --rather
>>>than build in what is missing into XForms 2.0 once 1.0 is shipped.
>
>I don't see why UIML should be limited to this area (meaning forms 
>functionality). UI components go way beyond that ;-)
>
>[1] http://www.w3.org/TR/xhtml-modularization
>[2] http://www.w3.org/TR/xhtml-m12n-schema
>
>Kindest regards,
>
>Manos


-- 
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC