Subject: [mmox] Use cases?

From: Jon Watte <[email-masked]>
Date: Thu, 26 Feb 2009 16:41:14 -0800

I posted five use cases that I think cover a fair range of virtual world 
interoperability. I've gotten several nice replies in the mail, but on 
the list they seem to have soared like a lead balloon, as opposed to all 
talk about XML vs binary vs IP property rights. Surely, agreeing on 
requirements (such as use cases) is actually more important than 
discussing implementation details that we don't even know will apply yet?

Any opinions, for or against, regarding these use cases? Silent assent?

http://www.interopworld.org/mmox-use-cases

Sincerely,

jw

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Thu, 26 Feb 2009 17:16:52 -0800

well... yes and no... use cases are important. but to prevent feature  
creep having a charter + a concrete proposal is always convenient. our  
charter is under discussion and is therefore at least "plastic" if not  
"fluid."

but yes. if i had it to do over, i would have published as much of OGP  
as we currently have defined along with LLSD as it's the application  
level that ultimately will be more interesting.

-cheers
-meadhbh

On Feb 26, 2009, at 4:41 PM, Jon Watte wrote:

> I posted five use cases that I think cover a fair range of virtual  
> world interoperability. I've gotten several nice replies in the  
> mail, but on the list they seem to have soared like a lead balloon,  
> as opposed to all talk about XML vs binary vs IP property rights.  
> Surely, agreeing on requirements (such as use cases) is actually  
> more important than discussing implementation details that we don't  
> even know will apply yet?
>
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox

---

From: "Mystical Demina" <[email-masked]>
Date: Thu, 26 Feb 2009 21:50:01 -0500

I think there are a lot of people that would like to contribute to these
discussions but don't understand the methodology that is being used so we
don't know when to submit comments into the process.  What I would expect is
something like Unified Process where this is a Strategic Plan Phase, a
Tactical Plan Phase, an Implementation Phase and a Transition Phase.  How
could that apply to this initiative is maybe something like this.

1. Strategic Plan Phase
Define the over all charter.  But I would suggest keeping it high level in
the direction of something like "creating protocols and standards that let
dispersed clients and servers integrated across a supply chain of various
industries".  Define the stake holders and layout the high level business
processes that are in this domain.  Identify limitations of the current 3D
environments, the big wish list from all the different stakeholders.  I also
think a lot of input we need to get will not come from virtual world
providers but from industry leaders related to situations that this
technology could help.  Everything from improved schooling of 3rd world
countries to designing a city, or building a ship or planning the next space
station on mars.  These are the problems that the virtual world technology
needs to address if we are going to be more than a form of entertainment but
instead the next generation internet platform for doing business.

2. Tactical Plan Phase
The tactical phases needs to takes this wish list of features and
capabilities and group them, segment them, organize them into use cases,
domain model basically identifying all the nouns and verbs related to
providing this supply chain.  It then needs to drill down these use cases in
enough details that really defines the problems we need to solve, the order
that they needs to be solved in.

3. Implementation Phase
For each of these use cases have a period for of request for comments where
people that wish to submit ideas and designs, existing standards.  I can see
this phase being a big deal and take some time.  All of these submittals
need to be against specific problems.  Then these need to be taken and
ranked by some kind of sub committees to create something that can be voted
on or how ever the standard comes to final stages.

4. Transition Phase
In this phase each of the use cases are matched against the designs, final
drafts are made and published.  People make final edits.  Voting is done and
a final draft of a standard is produced.  Really seems a wiki setup with
with reviewers may be a good way to do this.

So this is a quit presentation to get an idea across.  So to be honest I
don't understand these commits below.  I don't know of any system, standards
or plans that don't on a large scale that are ever accomplished with out
first understanding the process that is going to be used to accomplish the
goals.

So what I am afraid of is that the problem for this initiative is bigger
than the charter and is more in grained in what is the methodology that will
be used to accomplish the goals of the group.

I really salute Jon on starting a set of uses cases and hope that he doesn't
give up on them.  If we aren't going to follow some kind of methodology then
I think for me I probably will drop the group and not spend the time reading
these emails.  I guess there are others that feel this way too.

If there is a defined methodology for this group please send me the link I
would like to read it and understand how participation is suppose to work.

Meanwhile let me share a few a use case as food for thought.

I spent several years during the first internet boom working in the maritime
transportation supply chain, basically the interaction between oil traders,
charters, vessel owners, port agents, terminal operations, various services
at the port, supplies, financing, insurance, all these players that are part
of the supply chain to move oil from point A to point B.  Took 6 weeks just
to document the supply chain and to make a list of opportunities on how the
internet could help them work together better.  So now we have virtual
worlds and as I look into this problem space and say how virtual worlds
could help them do their business better.  I see lots of opportunities.
First there are tons of difference kinds of vessels and to learn them all
takes time.  I can see opportunities for these vessels to be created in 3D
spaces where people can get a real life look at them and when talking about
them can understand the details and location on the ship.  Ports have lots
of various layouts, risk and issues.  I see an opportunity for mirrored
virtual worlds of ports.  Terminals have lots of different configurations
and issues.  There are tug boats, fueling vessels, loading vessels.  So
let's say we could render all of this up into 3D.  It would be lots of
different companies need to share objects, link together real time data like
locations of vessels.  Staff from different locations would need to be able
to teleport into different locations to look at stuff.  There would have to
be integration with legacy systems in bound and out bound.  I could call
them tomorrow and talk to them about this but I don't think I could sell it
because there isn't a standard yet that they could invest in for al the
parts to talk together.  They can't call up one of their partners and say if
you implement this we will do it too.

I know someone will say we need a protocol for these to talk together, so
let's define a protocol.  If so I would say we don't have the right
leadership in this group and it will fail.  I think starting with a wire
protocol to solving how a supply chain works together is doomed process.

These are the kind of problems I would like to solve.  I hope they are what
the group would like to solve too.  I would like to participate in a
constructive manner to solve this kind of problem.  I hope the group can let
me know how I can do that.

Kevin Tweedy
SL: Mystical Demina
http://www.XRGrid.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Meadhbh Hamrick (Infinity)
Sent: Thursday, February 26, 2009 8:17 PM
To: Jon Watte
Cc: [email-masked]
Subject: Re: [mmox] Use cases?

-cheers
-meadhbh

---

From: Jon Watte <[email-masked]>
Date: Thu, 26 Feb 2009 21:30:03 -0800

> and issues.  There are tug boats, fueling vessels, loading vessels.  So

So far, what you are describing a specific application (not unlike some 
pitches that we've heard at Forterra, btw -- I guess the business you're 
in really might benefit from virtual worlds technology). Specific 
applications might be good as example input into a standardization 
process, but should not be the single driving factor behind such a process.

> be integration with legacy systems in bound and out bound.  I could call

I think it would be really valuable if you could re-work that into some 
concrete use cases, from which requirements can be gathered. Do you 
think that would be possible?

> protocol to solving how a supply chain works together is doomed process.

I think the reason we're saying that a protocol is needed is because we 
do know that a protocol must be needed. These are computers. They talk 
over a network. That happens through protocols. Once there is some form 
of standard protocol, a business built on standardization can take off, 
but the business can't come first, because there would be no "there" there.

Consider the work you did where you made the different pieces work 
together through the Internet. You couldn't have done that, had there 
not already been an Internet. The Internet runs on IP, and TCP, and BGP, 
and DNS, and a large number of other protocols. Had those not already 
been there, your Internet-based business process improvement could not 
have happened.

That being said, I believe that business process input into the 
requirements is both valuable and necessary. Personally, I have already 
seen that kind of input from several customers and partners that I work 
with in daily life, and that's why I'm here -- I have, internally, 
synthesized the requirements I hear from parts of Federal Government, 
Enterprise IT, Healthcare, Web Collaboration, Education, Non-profits and 
other organizations, and even the Entertainment space in the form of our 
PG-13, white-label partners at Makena. I have, internally, worked that 
up into use cases (some of the most illustrative of which I've posted in 
the previous thread). I have then, internally, knowing of the technology 
of a large number of systems (not just "mine"), come up with an approach 
that I believe delivers the most "bang" for the least "buck" in terms of 
solving actual customer requirements. Of course, that's all internal to 
me, and not only can't you read my mind, you have no particular reason 
to trust my particular judgement. If we can collect a bigger set of 
requirements and inputs from the users who will benefit, that would be 
just great!

Sincerely,

jw

---

From: "Mystical Demina" <[email-masked]>
Date: Fri, 27 Feb 2009 01:50:11 -0500

It take a few days, will try to have something early next week.

>From: Jon Watte [mailto:[email-masked]] 
>Sent: Friday, February 27, 2009 12:30 AM
>To: Mystical Demina
>Cc: [email-masked]

>Jon Watte wrote:

---

From: Jesrad <[email-masked]>
Date: Fri, 27 Feb 2009 12:16:06 +0100

The use cases certainly help focus on the "meat" of the protocol,
however they can also easily miss entire domains of application for
the protocol, so they won't be the sole source for listing
requirements. We could exhaust every cross-grid way to exploit each of
the VW features that are to be transported by the MMOX protocol, but
then it implies we know which features these are. And some use-cases
may extend the scope of interoperability way more than necessary or
desireable for the people for whom MMOX is intended.

That poses a problem: not all VWs will be interested in sharing all
their features cross-grid, nor even all the features they have in
common with other VWs, so I think the MMOX protocol needs to define
levels of partial compliance, possibly in the form of a dependencies
tree. I believe making sure some interoperability is sufficient while
not mandating all-inclusive interoperability will appeal more to the
"big players" that are still not represented in this group.

We've also seen already that some VW services are interdependable
(there's little sense in having financial exchange capability without
identity and auth, or 3D representation without contiguity and
presence simulation) but that many such "bundles" (like the division
in Agent and Region domains in OGP, if I'm not mistaken) can operate
seperately. We've seen too that it implies some capacity, for
MMOX-compliant VWs, to multi-source those bundles of services.

So we may well need to fuse all the features that are interdependant
together, while avoiding any cross-dependancy among them when they
don't.Think of it as "interoperability à la carte", but with only
menus of grouped services and not individual ones to pick from and
support in each VW. So the partial implementation of MMOX would still
mandate that each such bundles (Domains ?) be supported in full, or
not at all.

So I suggest use-cases only come after we get a good idea of what
features' PDUs the protocol will transport, and how they might be
grouped together. When we have that information, exploring the
functional possibilities and thinking about what interoperability
would make possible for the end user will be easier and probably more
exhaustive, while avoiding the potential pitfall of requirements that
could degrade the "palatability" of the protocol to some big players.

On Fri, Feb 27, 2009 at 2:16 AM, Meadhbh Hamrick (Infinity)
<[email-masked]> wrote:
> well... yes and no... use cases are important. but to prevent feature creep
> having a charter + a concrete proposal is always convenient. our charter is
> under discussion and is therefore at least "plastic" if not "fluid."
>
> but yes. if i had it to do over, i would have published as much of OGP as we
> currently have defined along with LLSD as it's the application level that
> ultimately will be more interesting.
>
> -cheers
> -meadhbh
>
>> interoperability. I've gotten several nice replies in the mail, but on the
>> list they seem to have soared like a lead balloon, as opposed to all talk
>> about XML vs binary vs IP property rights. Surely, agreeing on requirements
>> (such as use cases) is actually more important than discussing
>> implementation details that we don't even know will apply yet?
>>

---

From: Jon Watte <[email-masked]>
Date: Fri, 27 Feb 2009 09:50:03 -0800

> the protocol, so they won't be the sole source for listing

I don't quite understand this statement. It sounds to me as if you 
believe there are intended uses for a protocol that you cannot describe 
a use case for. That sounds a little oxymoronic to me -- if you have an 
intended use, that is per definition a use case. Note that I do not 
believe my 5 use cases are the end-all of virtual world 
interoperability; just an illustration of what I believe the low-hanging 
"actually useful" fruit would be. Please contribute more use cases if 
you have other intended uses!

> "big players" that are still not represented in this group.

I don't think any mandate can be done. Even with a standard protocol, 
you can choose to not provide certain information. For example, a HTTP 
server can choose to not serve a given document, either by sending a 404 
not found, or a 401 denied, or some other method.

> features' PDUs the protocol will transport, and how they might be

I think that's putting the cart before the horse. The use cases define 
what we actually need to work towards. If there is no use case for a 
feature, that means there's no reason to implement it, because nobody 
will use it. Meanwhile, if you don't have use cases, then you can't 
tease out what things you actually ought to be building.
Note that use cases are all about *what* you build, though -- not *how* 
you build it, which I feel is what you're trying to get at.
De-coupling and separability (as you describe) are all very useful 
traits in a technical design, but are all about the "how," not the "what."

Sincerely,

jw