Re: syntax, model
tbray@t... (Tim Bray) writes: >> Most of the documents I create personally have no schema. The data >> model is open, defined only by the instance. The code I write for >> processing these documents requires no schema. The code has its own >> data model, which may or may not resemble the structure of the >> document. > >Me too, for the frequent occurrence of cooking up an ad-hoc vocabulary >for some particular problem. For a language that's going to be >widely-shared, you really ought to write a schema (preferably .rnc), >for three reasons: Most of the documents I create this way aren't widely shared, and I think the assumption that most XML documents actually are made to be shared in any formal sense is probably mistaken. Still, they do sometimes grow into something other people find interesting or useful. >1. It forces you to write down your design formally and exposes > glaring gaps in your thinking. It does for me, anyhow. Yes - this is true whether or not something's shared. If it's done after a few rounds of emergent markup, it's also interesting to examine and consider the patterns that emerge. I'd really like to see something like Trang's schema inferencer that works across multiple documents. Maybe that's too evil a request, and Examplotron is a good middle ground I should use more often. >2. It's useful documentation, there are those who really find schemas > easier to read than instances. Weird but true. There are a few people like that, yes. I find schemas useful primarily because they're concise. >3. It gives you some basic quick-and-dirty validation. Schema-only > validation is almost never useful at a business level. I use schema validation regularly for material going to O'Reilly's production department. I suspect that spares them some minor inconveniences, but it's still remarkable how many cases are permitted by the schema but not by tools - and vice-versa. I don't think O'Reilly is at all unique in this, of course, and I'm generally pleasantly surprised by how smoothly things go. >An example that illustrates both 2 and 3 in the list above is the work >on Atom; clearly something like this needs schemas for reasons 1 and 2, >but the excellent feed validator does not use a schema-based approach. I suspect schema-based validation should be treated as an anti-pattern in a lot of cases, something worth doing at particular points in the development and creation cycle but dangerous if used as a general (and particularly as an exclusive) mechanism for inspecting information. Schematron seems like an interesting mechanism for addressing those kinds of problems, and maybe patches things enough to make the general notion useful. I'd have to spend more time with it to decide.
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