Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Nested schemas
 I am just starting with XML and appreciate this list. Here's my first 2 cents worth (ISDN dial up means it probably costs .003434 cents except for the wasted time connecting) I have some background with databases and text processing (troff project in 1982- 1984 and Tex in 1986-1988) and also distributed SQL databases (1988-1994) and so I thought that XML has some very interesting features. I am not sure where some of the discussion on this list regarding semantics or theoretical stuff is going to go but hey go for it if it helps your projects or the language. My take on XML at this stage is that it solves an age-old problem for coding - the parser. Its really a drag building ASCII/TEXT oriented parsers for small utilities and the like. So, first off XML is a generic parser without YACC or more cryptic tools some of us have scratched our heads over. Some applications take parsers better than other. That's just a fact of information as far as my own personal experience has shown. If true, then XML is going to be more quickly adopted by applications which in fact already have parsable information, such as HTML based, and which are designed for one single function, such as displaying information. In terms of nested schemas, a point to point type application, such as one client - one database server, is probably going to be easier to use XML than a distributed, multi-node application which requires integrating several data sources simultaneously. Embedding different types of data from one app within other types of data from other apps works better/easier for specific tasks such as displaying that data (HTML or other tagging document approaches) than it does for open-ended manipulating that data. The reason is we are ASSUMing that the data from different sources has some interrelationships with each other. The reason it works well for display is that we're really only concerned at this point with ONE application - the display of the information from multiple sources. Most applications know at least how to display information, so that is a lowest common denominator function amongst many many apps. We really are not asserting that the information is even coming from multiple sources - multiple physical locations, sure under web approach. But the generator of the information could be just one application as far as the display application is concerned, and its role is one specific task. Other tasks like hyperlink are relatively simple extensions to the display (here it comes) paradigm. Manipulating the information from multiple applications is a huge step, since applications are still in their infancy regarding inter-relationships. To this line of thinking, using XML in the case of complex documents from multiple applications is "merely" the formalization of the inter-relationship between those applications. When and if there IS such an inter-relationship, it could be asserted that XML would prove the formal rules do in fact apply and the inter-relationship is proven. If we are stating we want to create that inter-relationship and XML is the method of externalizing that inter-relationship, then that's a good first step. Externalizing information relationships isn't new to information models but it also isn't easy. Object models appear to be more flexible but they still take a lot of work to be effective. Any technique is inherently limited since we are formalizing something that may never have been formalized previously. That doesn't mean the technique is inadequate - but it does mean the technique brings some constraints that must be reflected somewhere - usually back in the applications using the technique. Nothing wrong in that. So, where does that leave us with 'nested schemas'. The first issue I see is that the syntax may overlap between applications. How do we deal with that 'cause long term that will make XML a dead end for anything like the lingua franca that some proponents are calling this approach. The reason is that application development is still primarily done for specific tasks and business issues - the need to cross-boundaries should be made easier by XML. However, XML must then have very simple techniques to support the different information models it is parsing. How do we ensure the parser is told to switch between 2 or more different information parsers which use some common words in different ways? I think there's a need to resolve this issue - course I may have missed the easy way to do that. I think there's enough brainpower out there to solve something as basic as this. If there are proposals already out there, can someone summarize them with pointers to their design? My personal interest is in the combination of parseable information with command driven applications. CLI type utilities are prime candidates for XML 'cause we can use XML syntax to join the CLI commands with the information required to be processed by the CLI. XML doesn't directly support an event driven application syntax. To my mind, it would require built-in XML event blocks for the parser so that the parser could in fact be data-driven to interoperate with the application more easily. I see the parser currently as query driven from the application, where the parser is expected to read in a "document" as one block and then it is broken down into the tagged components. It would be interesting to see how XML could be used instead to inter-operate between the parser and the application where there were staged parsing based upon information within the information. This extension would need to be supported in the DTD so people could easily tell the XML parser when and where to breakdown the information. In general, XML enhancements need to focus on how to improve the parser. We need more than ELEMENTS and ATTRIBUTES as fundamental parser controls if the basic parser is going to be improved to support a wider range of applications. I'd like to see EVENTS discussed in relation to nested schemas for example to help the parser switch schemas. We need to look as whether issues like nested schemas is really leading us toward something more powerful for the parser and therefore more helpful to alot more applications. Thanx and I look forward to reading more about specific XML application development problems. ...bryan F. Bryan Cooper 707 823 7324 VERITAS Software 707 321 3301 mobile Bryan.Cooper@v... 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
|
|||||||||
