Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Compound Documents - necessary for success?
 At 05:52 PM 2/2/99 +0000, Mark Birbeck wrote: > >Well, sort of. But note that you can use namespaces even without using a >DTD. A standalone document that is well-formed might still want to have >the following, in order to provide clues to any application that is >processing it: > > <xml xmlns="uri:mybits" xmlns:dt="uri:datatypes"> > <person> > <name dt:type="string">Fred</name> > <contract type="short-term" /> > <hair type="greasy" dt:type="string">blonde</hair> > </person> > </xml> > >In this example, if the application was going to process 'type' in a >certain way (say an XSL processor), then it needs the namespaces to help >it work out which 'type' is which. Also, if the namespace wasn't there, >then you wouldn't be able to use both 'type' attributes in the same >element. But note that no schemas need be involved. Without a DTD or schema on which to "hang your hat", so to speak, you're vesting the application with the knowledge of what the various namespace-qualified constructs mean. This strikes me as a Very Bad Thing, because it leaves individual applications to interpret (potentially, interpret very differently) what a particular attribute or element means. Generating a specific meaning and rules for usage for a particular DTD or schema isn't "automagic", but at least it forces people to think about what they're doing and lends some semblance of order. For small applications you can get away with not having such an anchor point, but for anything larger than a few documents you're asking for trouble. > >Conversely, if you devise a DTD that uses another DTD, you don't >necessarily need to use namespaces. In the height/player example given >before there is no ambiguity, so why would you introduce a namespace? Granted, as long as there are no conflicts in naming between the DTDs. However, as soon as you change a DTD you get into problems with DTD versioning, and as soon as you clone it to add the new DTD reference the proliferation of DTDs introduces a potential management problem. Yuk. > >So, back to compound documents. I think as a stop-gap you need dynamic >DTDs. Just as many features of XML are best implemented using dynamic >documents generated from databases, why not generate a top-level DTD >that contains whatever lower level DTDs it needs to define the relevant >compound XML document? The top DTD would include some basic stuff for >containing a list of documents, and then include whatever other DTDs it >needs for each document in turn. In order to do what you're proposing, you have to have knowledge *somewhere* of what is and is not acceptable... just as RDBMS catalogs govern the creation of dynamic DTDs for database data, so you would have to provide some sort of intelligence in your DTD generation mechanism to prevent unwanted, ambiguous usage. Chris ------------------------------------ "Beware of all enterprises that require new clothes." -- Thoreau 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
|
|||||||||
