[
Lists Home |
Date Index |
Thread Index
]
Didier PH Martin <martind@netfolder.com> writes:
<snip/>
>
> > I think what you call the interaction model might be our "abstract
> > object model". That's the end result of running XSLT
> across all the
> > various models to combine them into a single model. We then can
> > transform this abstract model using different presentation XSLT.
> > We've basically got ECMAScript/XHTML and Flash as our mix, sounds
> > pretty much equivalent? (Other presentation model targets are PDF,
> > Word and Excel, but so far no actual implementations.)
>
> Interesting, If I understand well, you create an intermediary
> model aggregating other models, do I get it?
Yes, I think so.
As I said, we've got multiple models, some coming it from a cross
organizational points of view, some coming at it from other points of
view. I look at it as run time rule evaluation to come up with the
object model that suits the current context.
One long term goal is to handle things like privacy requirements where
patient populations are small and if a user can combine say birth date
and place of birth they can determine an individual. To make things
like that work you've got to be able to take past usage into account to
determine the current allowable context. Bump it up a layer and you've
got the same requirements for metadata, but trying to come up with an
understandable example makes my head hurt at the moment...
> It seems that
> your abstract object model is what we have with PDML. A PDML
> instance is then transformed into a representation. In the
> case of a user interacting with the object, we transform the
> PDML instance into a rich client app like you do. So its
> seems that your abstract model is equivalent to our PDML
> encoding. Our value chain
> is:
>
> XMI -----> PDML ------->XHTML/ECMAScript/etc.
>
> For each step we use XSLT as a transformation tool. But like
> I said previously, when we use XMI we have to limit the
> association types to the ones provided by UML and we found it
> too restrictive to fully model any knowledge. UML would
> benefit if the association could be custom typed as the
> objects can be.
I've got a partially completed paper where I discuss using UML in
conjunction with other modeling technologies because of this limitation.
The basic idea is the old one that you should be able to use the
modeling tool of your choice for the problem at hand and store the
results in a common repository. (Makes me wonder if System Architect can
expose it's repository in a relational fashion or as XML...)
>
> > We're doing all the transformation on the server side,
> partially for
> > security reasons. For us, part of presentation production is
> > traversal of authorization models and data. If you're
> doing that on
> > the client side don't you run the risk of allowing the
> client to peal
> > back the transformation and get at things you don't want them to?
>
> This was the subject of a lot of discussion. We resolved that
> by providing a subject representation. Users see only the
> part of the model they are allowed to see. Off course, the
> code itself is open but for an intranet it is not a big
> issue. For software sold on the internet it could be. So even
> if the object has more properties and methods, users see only
> the subset they are allowed to see. We refine the notion of
> "subject oriented" to the concept of representation. A
> subject being a representation.
>
> > It's an after the fact rationalization, but; that's seems
> partly why
> > we have a metadata model that's not coded directly in XML:
> you want to
> > be free to produce multiple model representations as needed...
> >
>
> Good point, we found that too. You need to store the object
> metadata separately from the object especially if the object
> is created with object oriented languages.
>
> Peter it seems that you are moving toward more modern
> environments, we should exchange more.
Gee, I'm not sure if I'm ready for that kind of relationship yet ;-)
Seriously, I've noticed the threads you start often seem to be relevant
to the work we're dong here. However, we're so swamped that trying to
do much more external communication is sort of daunting...
|
