OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   What Are Components in XML Languages? (Was RE: [xml-dev] RE: Auto-comple

[ 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.




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS