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: Re: HM.interactions: initial questions


> Mark Brownell wrote:
> > From: Manos Batsis
> > >Although SOAP and/or XML-RPC are very handy as "semi-protocols", I don't
> > >really find a reason to focus on them while building our framework; They
> > >are just a distributed computing "API". Essentially, it's just a way of
> > >messaging. Shouldn't we be neutral towards these?
>
> I agree with manos. Don't put to much meaning into the technology. After
> all, it's just a piece of junk put together in a clever way. I respect
> people that understand this, but on the other hand, I think XML would
> have wanished a "long time ago" if it wasn't for all the people that
> _didn't_ get it. Unpredicted usage can be very constructive :-)
>

I see the RDF, server database solution as a workable technology that
could be implemented with existing tools. CGI is just too clunky for what
I would like to get out of it. My own shockwave application has spoiled
me on what I would hope to achieve. I also like the idea of me, sitting on
my butt and waiting for someone else to make it all happen. It is more
that likely that this will happen even if I blow all my remaining brain cells
on it anyway. I'm going to sit around here and watch the fireworks show.

> > So the bottom line for this idea is to provide the information to a commonly
> > used rendering machine. Has anyone provided a reasonable selection
> > process that determines what will end up being rendered on the user's
> > machine?
>
> What do you suggest constitutes this selection process? We have had
> discussions about approaches where HumanML could provide input to lower
> level technologies and middleware (EMOTE, HAnim, etc). Myself I have a
> very implementational approach to HumanML. HumanML, no matter how you
> described it, must present a use case where the primary focus is to
> render a noticable result back to the actors. If this will be a simple
> "DOH" or a complex "HMM", I really couldn't say.
>
> My biggest problem with HumanML right now is that it refuses to fit into
> any OOA method I know of :-)
>
> Cheers,
> /Niclas

Selection, that seems to be the primary issue no matter what structuring of documents,
databases, algorithms, or technologies are used. I propose to create a MTML tool that
works on as basic a level as I can get it down to. A tool that serves a purpose of networking
where volunteer efforts are rewarded back to the implementers of the network. I don't expect
people to jump on my band wagon, yet I'm going to keep developing this thing because
at this time it seems interesting to me. I just want the RDF, that I will use, to outlast this
project
if it turns out to be a dead end. I'm not being creative for the sake of a HumanML. I'm way
more interested in creating a SW that works. HumanML offers some interesting values to
a SW, I have learned. So I'm going to see if I can create an input layer that addresses this
form of semantics. Undoubtedly I'll spin off some interesting code in the process. So that
seems worth it.

Best regards,

Mark



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


Powered by eList eXpress LLC