[
Lists Home |
Date Index |
Thread Index
]
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.
Best regards,
Nicolas Lehuen
http://nicolas.lehuen.com/
>-----Message d'origine-----
>De : Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
>Envoyé : mercredi 30 janvier 2002 17:34
>À : 'andrzej@chaeron.com'
>Cc : xml-dev@lists.xml.org
>Objet : [xml-dev] RE: Auto-completion in editors
>
>
>Yes, But.... It is usually feature choices. Again, the
>problem of XML it is just a syntax and a syntax editor
>even if augmented with a structural editor isn't enough.
>Once past these, it depends on the actual application but
>I think they will have a many features in common.
>
>Note: a compound document will be a freakin' nightmare for
>the editor vendor but that is why they get the money
>they get for these beasties (inquire into the price
>of a *good* animation system).
>
>Off the top:
>
>1. Multiple representations with integrated operations.
>
>In VRML, I need a treeview, dialogs, libary browsers,
>a pickable rendering view and the ubiquitous ASCII editor.
>Because it is a real time rendering system, I need timeline
>based event editors, behavior objects, and so forth. Because
>it is a ROUTEd language (events cascade), I need a way to
>pick on one object and get a display of available interfaces
>and engines, plus the option to create new ones (note that
>VRML routes through from event sources and sometimes through
>intermediaries such as timers to behaving objects - simple
>pipeline descriptions don't quite work here).
>
>2. I need to be able to configure or disable "helper"
>features such as intellisense and color coding. We
>can argue over initial states, ie, on by default.
>
>3. I need to export and import, translate and transform.
>
>I'm sure others can add to that list.
>
>Yes, they can get in the way, but so far I've been
>not too unhappy with XML Spy, Topolologi, and the
>still working Professional File Editor.
>
>Parts and assemblies: it's in the way that you use it.
>
>len
>
>-----Original Message-----
>From: Andrzej Jan Taramina [mailto:andrzej@chaeron.com]
>
>Len said:
>
>> Yes. Although the complexity of the application,
>> the use of high level editing controls that are
>> inserting library objects, and so on influence my
>> decisions on this. Different languages require
>> different tools. XML is great for the overall
>> generic tool, but this falls apart in the crunch.
>>
>> VRML is my best example. I need the IDE editor because:
>
>I agree with you wholeheartedly.
>
>The difficulty is that IDE's (in my experience) rarely provide
>the high level
>power and constructs that would be useful in a way that is
>unintrusive and
>simple. They "get in the way" more often than not (your
>example of automatic
>insertion of quotes is a good example of this).
>
>Don't get me wrong....if someone comes up with a good IDE for XML and
>especially XMLSchemas I'll be on my knees thanking heaven.
>But I have yet
>to see one (market opportunity....hint....hint!). Same with
>IDE's for Java/C/etc
>programming languages.....I have yet to see one that does not
>get in my way
>more than I can bear (and I have used all the big names). If
>you have found a
>good VRML IDE (something I have no need for personally) then
>that is super!
>
>'nuff said.
>
>
>Andrzej Jan Taramina
>Chaeron Corporation: Enterprise System Solutions
>http://www.chaeron.com
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://lists.xml.org/ob/adm.pl>
>
|
