[
Lists Home |
Date Index |
Thread Index
]
I mean that each application will indeed have
specialized requirements and that relying exclusively
on a generic editor doesn't work. So while we
know from experience almost any XML editor should
have a way to get to a generic syntax level editor,
after that, it becomes narrower and narrower.
Interdev won't work for X3D in the main. So
we agree. I do think there is a common set
of representations that work *ok* for the a large
number of applications, and that kind of thinking
leads to the components one finds in the MS common
control dll, and the objects in the IDE for placing
on forms.
Not new news, but if we see "the Web" as
just pieces and assemblies, the architecture for
that works first at the component level, and after
that, it's in the way that you use it. Today,
I wouldn't trust a lot of plugins to be compatible
for the same application language because the
semantic definitions are so weak. This has been
a major challenge for the X3D project and that
is to enable extensibility via components for
ONE language. It isn't a simple issue if you
can't get down to the COM level of things in the
specs. Do you think XML by itself manages that
level of definition? I don't.
On the other hand, nothing says a
well-designed set of components shouldn't work
together, and that is the trend I expect. It
will get messy in compound documents. The namespace
paradigm reflects, IMO, a database centric view
of the architecture. I am wondering if archforms
done with modern systems in mind (component-based
software) can do better. Big business for the
integrator.
This gets into the heart of What Is Hypermedia
and Why Was MAC86 the ultimate design but that
is a noodling thread for the history wonks.
len
-----Original Message-----
From: Nicolas LEHUEN [mailto:nicolas.lehuen@ubicco.com]
Len, are you sure that you should expect an XML editor vendor to support the
same set of features that you want for VRML ? I'd say that for this kind of
requirements, an editor dedicated to the application is more expected to be
satisfying.
I mean, it's difficult to expect a generic document editor to provide views
that require interpretation of the document (working at the semantic level,
not the lexical level), unless the document semantics are hardcoded into the
editor.
Maybe it could be made by having multiple layers in the editor : a set of
tools and views working at the lexical level (generic layer), plus a set of
tools and view working at the semantical level (application-specific layer),
that could be installed on top of the former in the form of plug-ins. Thus,
the vendor could provide its core product (with the generic layer), and
integrate its own or third party's application-specific modules.
Thus, specific market would be adressed by specific vendors, not always the
generic XML editor vendors. This could be a good thing, because generic XML
editors vendors won't take the risk of going on small markets or markets in
which they are not specialised. You can't expect a generic XML editor vendor
to provide an excellent X3D editor (with 3D preview and interaction,
timeline-based editing, etc.), and vice-versa. But a plugin-based system
would benefit both the generic XML editor vendor and the
application-specific editor vendor.
I guess we're back to the subject of managing plugins, i.e. associating code
to data to be able to work at the semantic level... And this time, with a
business objective :) But before we find a solution to this problem, there
is the question of how to write a decent generic XML editor.
|
