[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SAX-ext Attribute + Entity Parsing
- From: "Bullard, Claude L (Len)" <email@example.com>
- To: Justin Couch <firstname.lastname@example.org>
- Date: Thu, 01 Mar 2001 08:27:28 -0600
Ok. From that perspective I understand perfectly.
Everyday we get wishlists in our business at IPS.
We do our best to get them to happen if they
meet the general requirements for the product line.
We recognize that some requirements are purely
local and these we punt away to various utilities
if possible. Sometimes we get one that completely
rolls back the last two decades of progress in
user interfaces or standard data formats. In
these cases, the CS majors have to stand up to
the marketing majors and tell them to "eat the
spinach, it's good for you".
But in your case and knowing a bit about your
customer (if it is the consortium),
I'd say that would be tough. There
are areas in which I think some may be a little
cherry with regards to what XML and DTDs do,
and some where XML itself, with its multiple
and slightly incompatible data models could be
inadequate. The original split in the VRML
nextGen effort was (once the bracket wars
died down) over the abstract object model.
I have to wonder how many other XML language
projects are encountering this and what
about the models causes it. In the
case of X3D, the performance of XML relative
to a real time 3D animation model was
questioned. Many of the XML projects I
see or read about are strictly data projects,
as in database or static document models.
SVG is semi-animated; SMIL is a container
model for subdocuments (1.0).
When is the metalanguage design approach
the wrong approach?
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Justin Couch [mailto:email@example.com]
Sent: Wednesday, February 28, 2001 3:20 PM
To: Bullard, Claude L (Len)
Subject: Re: SAX-ext Attribute + Entity Parsing
"Bullard, Claude L (Len)" wrote:
> Be fair, Justin:
> 1. The X3D-Schema can be changed. The
> DTD needs to be dumped sooner or later.
Well, from my perspective, I have no control over the X3D spec. Being
purely blatant about it, the only reason I am working on the codebase at
all is that I'm being paid to do it. My perspective is that I've been
given a spec to implement and a bunch of wishlist items and I'm trying
to Make it Happen (TM). I'm certainly not here to change the spec. There
is a problem we have in that I cannot fulfill the specification given
the current set of resources in the SAX API and am trying to find the
best way around the problem.
> 2. They use parameter entities because
> the XHTMLers told them that was the
> "standard" approach to modularization
> and for some years, it has been.
Understood, but I need some code solution in order to implement the
required behaviour. My feeling that I'm getting from the feedback is
that it may well be impossible given the standard APIs so I may have to
go to a smaller, non-standard solution (Using the JOX DTDParser code for
> 3. Both Microstation and Autodesk are
> implementations, a bit long in the tooth,
> and X3D should not be hobbled by that. If
> it is, then it is not VRML200x but VRML 0.5.
Examples only of
a) How long it took to get some output generation capabilities (MS/SE
took 3 years to get acceptable VRML 2.0, not even VRML97 support). I
couldn't expect them to have schema support before dealing with DTDs.
b) As a person building a general purpose library for widespread use, we
have to deal with all circumstances being thrown at us - That is, we
_will_ get DTD content and we must make sure we play nicely with it.
My bitch is not with X3D per-se, just trying to find a clean solution
within the current standardised API sets. The answer I think I'm hearing
is that it can't be done today.