[
Lists Home |
Date Index |
Thread Index
]
We are about to walk straight back into the Doctype over PI
over attvalue in the root discussion.
From: Jeff Lowery [mailto:jlowery@scenicsoft.com]
>Perhaps more to the point is:
>Should one mix XML-formatted process descriptions with metadata?
>In other words, have one schema for process description and another for data
>description. Do these two descriptions have to be tightly bound in the same
>document?
No they don't and any GUI-property markup design, or IDEF-like
property definition shows one how to decouple. The whole idea
of MIL 87269 was to abstract the database away from the processing
description. We played around a lot with this in the MID design
because of 87269. For IETMs, it was just a matter of having an
engine for navigation according to a *view* minus any presentation-oriented
information such as might be found in a traditional stylesheet.
That is why we used a design for MID 1 based on a midi sequencer
because it enabled one to create mini-sequences that could
then be aggregated into higher level performances, sort of
like a Wizard maker. It actually worked. It isn't all that
different from any event-driven GUI except in the ability
to aggregate and to traverse pre/post condition systems.
It becomes an Orchestrator/Controller much like a MIDI
system (sends event data to any conforming processor). It
also meets requirements for some of the heady fractal
thinkers out there who like to talk about stratified
complexity and compartamentalized processes (but let's
not go there here: it's just abstract properties for
windowing systems with a bit of scripting).
Any time you send XML, regardless of wrapper, you are sending
data. It's just an issue of the receiver/interpreter doing
something useful with it. If you want to have some control
over that, make sure you read the UDDI. Even a bulk transfer
is conceptually Export(this.data) <--> Import(this.data).
Data warehouse designs often depend on exactly that.
len
|
