[
Lists Home |
Date Index |
Thread Index
]
Didier PH Martin <martind@netfolder.com> writes:
> > If you're asking can you do MDA for XML technologies, we're
> not there
> > yet. Some of the models we have to work with are:
> relational schema
> > for DB, UML for Java, but for XML we have loosely coupled
> requirement
> > trees. An XSLT modeling tool would be good: declarative UML
> for XSLT
> > anyone?
>
> Not exactly, I really asked is there anybody out there doing
> it. Now answering to the point you raised I personally do it
> through the following process.
>
> a) I create my model in UML (visual model) then export it in
> XMI ( a serialized version of it in XML format). Up to now we
> can consider that the model is still PIM (Platform independent model).
As I recall, you've "extended" UML to add relationship types not
normally included in the UML vocabulary? If not, don't you have the
problem that UML doesn't capture all the semantics you need?
> b) Then I transform it into another format I created that
> mixes RDF and Xlink so that I can use XML to surf the object
> association links and RDF to parse the object's property set.
> I am in the process to add methods, both local and remote
> (SOAP). Local methods are methods running in the browser not
> limited to it. I consider a method as a representation. Hence
> my object have more than one representation and thus can be
> perceived as "subject oriented" objects.
This is where we just throw it into our metadata store: objects and
attributes in a relational database. Not as extensible in the XML
dimension, but I think our underlying requirements are different: we're
building an app to support the collection of research data.
> c) I use XSLT to transform my domain model into an
> interaction model. An interaction model is a set of
> components users interact with to change domain model
> object's state. Usually my interaction model is encoded into
> a mix of ECMAScript/XHTML/applets/SVG and SMIL.
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.)
> d) the app runs on the client side not on the server side.
> Hence the server's role is restricted to provide a domain
> model encoded into an XML based language. On the client side
> a transformation rule is sent with the domain model and the
> client environment produces a just in time app based on the
> transformation rules and the data (i.e. the domain model).
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?
> I discovered that in order to be model driven object have to
> present more than one representation. For instance, a SOAP
> representation (i.e. a WSDL document used as interface
> definition hence an XMI to WSDL transform), an interaction
> representation (stuff running in a browser), a XAML
> representation (in case we want to run it into a longhorn
> environment), any other representation.... Web objects should
> be very different from classical objects limited by s strict
> single minded signature.
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...
>
> Anyway, from the answers, I see that yes indeed we are far
> away from it...
>
Sigh, ain't it the truth!
Peter Hunsberger
|
