[
Lists Home |
Date Index |
Thread Index
]
We describe them in Query By Example (QBE) terms.
They are good for authoring data, but somewhat
awkward for mining the data. One can use them
for data mining, but one has to be very aware of
the data relationships as expressed in the
GUI going into the effort. Forms are structured
GUIs. The documents are the reports.
In context of the thread title, even before XML,
the markup community discussed the potential of
markup to support data fusion technologies. This
is still of great importance to the content owners.
One off publishing is not where markup excels although
one should not deprecate it for that task given that
future importance of information is not always known,
so it is not a bad idea to ensure it can be reused.
The editing tools should be appropriate to the
task at hand. The storage formats and the
annotation by markup should be future proofed.
This can conflict with the message/serialization-of-objects
uses which emphasize size of the message as well
as consistent interpretation based on observable
behaviors (ontological commitment).
XML experts must become experts in the trade-offs.
XML content owners must come to understand these
as well. Otherwise, the procurement of the system
will come up short.
len
-----Original Message-----
From: Rick Jelliffe [mailto:ricko@allette.com.au]
From: <AndrewWatt2000@aol.com>
> In a message dated 18/02/2003 05:08:26 GMT Standard Time,
> ricko@allette.com.au writes:
>
> > I don't believe users are happy.
> >
> > At least, not the publishing users. By making it easy for developers, we
> > have a lot of software which is good for data transmission but still very
> > little that is an advance for data capture.
>
> Rick,
>
> Isn't XForms supposed to fulfil at least one aspect of data capture?
Sure, but what kind of forms interfaces does it give us that we didn't have
before with the non-XML technologies? And forms interfaces seems
most geared to the interactive and catalog-market niches.
|
