[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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? Len http://www.mp3.com/LenBullard Ekam sat.h, Vipraah bahudhaa vadanti. Daamyata. Datta. Dayadhvam.h -----Original Message----- From: Justin Couch [mailto:justin@v...] 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 example). > 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|