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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: SAX-ext Attribute + Entity Parsing

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

-----Original Message-----
From: Justin Couch [mailto:justin@vlc.com.au]
Sent: Wednesday, February 28, 2001 3:20 PM
To: Bullard, Claude L (Len)
Cc: XML-Dev
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.