[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: VRML and XML
W. Eliot Kimber wrote: > Len, > > You are confusing the specification of the data with the execution of > the specification. It's like saying there'd be some difficulty in > representing a programming language using XML syntax--there's not. No. SGML-bred, I understand that completely. MID was a good laboratory for those concepts. I am looking at the practical applications and wondering if there are any right now. *Internet time* has taught me to be self-restrained about what is possible vs what is worth the effort given the need to get the software to market. Whatever else the VRML community does, they are very pragmatic about that. The VRML community is almost completely unique in the close symbiotic relationship in the development lists of the the content and implementation engineers. It has been a raucous but very effective relationship. A syntax specification language can represent whatever needs to be represented. It has been done several times with SGML as we both well know. Building a production-worthy useful language is not a theoretical exercise however. For an XML version of VRML to be useful, there must be some requirements for it which ISO VRML (VRML 97) does not meet. > Using a style language is useful for the same reason it is in SGML: I > want to apply different styles to the same basic data objects. Asking > why it's useful here is like asking why you need styles if you have a > font tag and I know we both know the answer to that one. Yes. If one is considering building reusable objects in scenes, there may be something useful there. However, VRML97 already contains protos and external protos which satisfy that requirement and are expressed in an established syntax for which there are already good and rapidly improving implementations. VRML is designed around an object model and in some respects, is ahead of DOM. > The fact that the presented result happens, in some presentation styles, > to be interactive is completely irrelevant to the issue of representing > the data using XML. In the theoretical sense, yes that is true. In the practical sense of fielding applications, it is also irrelevant. The *presentation styles* of 3D graphics are not that complex and it may be the case that within the current and soon to be fielded platforms, the size of the instance, the speed of the parse, the building of the internal structures, the efficiency of the external interfaces are the critical aspects of the design. > A better question might be: does XLL (or HyTime event schedules or some > combination thereof) provide anything useful in representing the > relationships among the nodes, which is all an event model does (define > relationships or behavior associated with relationships). Yes. I think that is the more interesting question. The linking of VRML is still a list of URI/URLs where the intended semantic is to try the first one and if that doesn't work, try the next one, etc. VRML anchors are not that sophisticated. It was said that because of script nodes, they did not need to be. It is an interesting decision in what it expresses as the preference of the VRML designers with regards to abstractions of semantic linking. However, see below for a real problem which the URLs, scripts, and event models don't solve given the current VRML expressive limits. > XML only operates at the document representation syntax level, so it can > have nothing to say about the semantics of the data represented. On the > other hand, XLL and HyTime (and DSSSL and XSL) operate at the semantic > level and therefore may have lots to say about the semantics of the data > represented. Yes. I think that the project should look at the DOM for its potential to unify the document handling framework. IOW, would the benefits of minimizing the number of interfaces for handling documents of multiple notations outweigh the performance benefits of multiple, notation-specific APIs? Given that the building of a Web page is now approaching the complexity of a Visual Basic application, the size of the browser framework (cum portable operating system) is getting above 15MB, and the willingness of the vendors to increase the number of 5MB+ plugins (notation browsers) within the framework deliverable is waning, there may be benefits. However, in the case of VRML97, at this time, the performance (frame rate, load time, time to load and start included files such as MPEG, WAV, streaming media), is critical. BTW, in the timing problems, VRML browsers still have sticky problems particularly in execution where indeterminate conditions can occur. This makes some problems of sequencing almost intractable for the content providers as the machine characteristics are critical. IrishSpace pushed the envelope. The script I mailed to you is the opening from that project. Just for grins, try to figure out sometime how to get the asteroid to always hit the Amazon Basin and start the transparency that creates the ashcloud to happen exactly when the script says it should. The problem is one in which the audio has begin times and event outs for when the audio is done, but no way to state exactly where an event within the audio occurs. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
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
|