[
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
software.
It happens. R&D gets turned into product and no
one notices until it is late in the day that they
have created YetAnotherXMLStovepipe.
len
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.
|
