Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] best markup practices, different communities
 After spending ten days on a cruise ship presenting and discussing XML, I'm starting to have some serious doubts about what XML brings to developers in various communities. The doubts are not about the value of markup itself, or the enormous possibilities opened up by cleanly labeled structured documents. Markup itself, Ted Nelson's doubts aside, has proven to be remarkably powerful and useful stuff. Reusable tools are great for lazy programmers (that's a compliment!), no doubt. What I am worried about is a lot of the best practices that inform the creation of XML standards and XML documents. The large-scale publishing experience that informs what I typically refer to as 'XML best practices' doesn't seem an appropriate influence on other applications of markup. There are plenty of cases where I sincerely doubt there is 'one true way' for document, data, and Web folk - these different fields have different technical requirements for information handling, some of which overlap in odd ways. Separating content from presentation makes an enormous amount of sense if you're publishing content to multiple media targets or designing relational database tables, but very little sense if you're creating user interfaces which need to contain some logic in the markup used to define them - DHTML, XUL, etc. (I find it ironic that the Web community could probably benefit most from processing instructions, but the World Wide Web Consortium openly discourages their use.) Mixed content is critical to both document and Web developers, since both spend so much time working with the messy structures that humans tend to create, but can be a huge nuisance for data-oriented developers who wonder why the document folks are too lazy to add the extra markup necessary to avoid the need for mixed content in the first place. The '&' model, which works extremely well for database recordsets and is effectively used every day all day in a wide variety of application, has somewhat catastrophic problems when introduced to the rest of the XML grammar, and was therefore excluded. Data-oriented developers now get to worry about sequence on a much more regular basis. I'd also suggest that project scale plays a substantial role in best practices, and that smaller projects may need fewer but sometimes more tools to make them work as their developers would like. Enormous technical documentation projects and small-scale hypertext poetry can both make effective use of markup, but I'm not sure that the requirements above and beyond cleanly structured labeled content are substantially similar. Tim Bray just wrote: > So I say to you all: go back in your caves and come out with > *one* schema facility that lets me write grammars when I want > to and xpath expressions when I want to, and has an elegantly > unified syntax. Then declare victory. For extra credit, > replace entities too (just kidding). -Tim I think it's time to give up on the dream of a single facility for all of that, and start focusing more on best practices which are appropriate to particular communities. Think about allowable subsets of functionality rather than demanding the 'there can be only one' approach, and standardize only where it's both possible and relatively easy. XML 1.0 standardized the 'relatively easy' stuff for markup itself, though I wish more and more that DTDs had been defined in a separate document. I'm not convinced that we can find nearly as much uniformity of purpose at any level beyond the foundation. I do have hope that we can do interesting things, however - I was impressed recently to see Murata Makoto defining a separate set of rules for processing data-oriented information using RELAX than the document-oriented rules of RELAX Core. It's an interesting approach to using different sets of rules, which can be used in a common processing environment while preserving the understanding of different contexts.: http://www.egroups.com/message/reldeve/207 Something like that, rather than solving all problems with a single set of tools, seems like a less combative and potentially more extensible approach. Assuming that a single solution is possible by merely separating the technical from the political seems to me like a recipe for unrewarding collisions and pileups over the next few years. Simon St.Laurent - Associate Editor, O'Reilly and Associates XML Elements of Style / XML: A Primer, 2nd Ed. XHTML: Migrating Toward XML http://www.simonstl.com - XML essays and books 
|
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
|
|||||||||
