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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Top 10 commercial XML vocabularies?

[ Lists Home | Date Index | Thread Index ]

I agree with you.  Still, one can find oneself 
facing an irate programmer certain that he/she has 
invented a new approach and defending the running 
code and local consensus.  What they probably should 
do is extend it based on their own namespaces.  
Instead, they start altering the vocabulary itself 
to kick off their own algorithms.

How does it happen?  Easy:

1.  An implementer not completely familiar with XML  
chose based on what is popular and failed to notice 
that namespaces are used for extensions.   Say Hack. 

2. Customer not familiar with all of the XML vocabularies, 
so chose based on implementer recommendations.  Say good 
faith but a consensus of the uninformed.

3.  They buy into the 'extensibility' of XML and 
assume they can change tags as they will as long 
as they can JavaScript it.  They missed the class 
on syntax vs. vocabulary or didn't bother.

4.  Given laws and requirements such as "Thou shalt 
only use W3C specs", they wind up in the crack between 
the specs.  Say, they have 81/19 requirements.   

5.  They can start out wanting just a touch of 3D, 
discover later they want more, then discover somewhat 
belatedly that they have already created momentum and 
legacy without direction.  It works but only with 
their code; so regardless of XML being applied, 
interoperability is compromised because once again, 
someone confused portable data with interoperable 

It happens.  R&D gets turned into product and no 
one notices until it is late in the day that they 
have created YetAnotherXMLStovepipe.


From: Robin Berjon [mailto:robin.berjon@expway.fr]

Bullard, Claude L (Len) wrote:
> If I understand your mail, the implementor chose 
> the wrong language.  X3D could be a better 
> choice for that particular application based 
> strictly on what the customer asked for.

That is hard to tell without knowing what the customer required. If it 
was mostly 2D with a few touches of 3D then SVG might have been a good 
choice. If on the other hand it involved elaborate meshes, NURBS, etc or 
a great number of 3D objects I'm much less sure that SVG was a good 
choice. As far as I can tell, it was designed to be 2D.

> It 
> becomes a problem if the customer then demands 
> that the 3D version be considered a standard 
> and presses hard in their own community for 
> that without understanding the 80/20 philosophy 
> espoused by the SVG community.

If they have that bad a need for 3D why are they turning to SVG? And if 
they really do need something that is very much like SVG, only with 3D 
included, why not draft a standard that defines an extension to SVG (in 
a separate namespace and so forth)?

>  Do you think 
> the mainstream of the SVG community has the 
> same opinion about SVG being 2D only and 
> feature-complete? 

I can't speak for the entire community. From the discussions I've had, 
most people don't use SVG 1.0 in its entirety already. I have rarely 
heard of feature requests that could not be implemented through 
extensions, and whlie I can't read the minds of the WG members if SVG 
1.2 goes where it appears to be going then there won't be imho much more 
to ask for, and I certainly hope that that opinion will be shared by the 
majority of the SVG community. It is shared already by those that I have 
  been in contact with.


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

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