[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: syntax, model
You touch on two points of interest: 1. That schemas can and should be treated as emergent controls, and that within them, local emergence can be observed (some parts of them perturbate in fascinating ways and finding the coupler is a great exercise for enterprise modelers). 2. That schemas can be used to tighten down a pipeline opportunistically and in some cases, tighter than the other tools being used. In fact, that has been a major use where I've used them or seen them used. What some know from hard experience is that local rules prevail and that a schema is fine way to localize. They are, as Tim notes, not particularly good for business rule processing; on the other hand, as people are likely beginning to notice, a lot of the business rules that were tied into the GUI logic (eg, onFocus: check that; if not that, display error dialog) are difficult on the web in general given granularity, statelessness, and loose coupling. It would be illuminating to see a real world case of enterprise class applications running on the web to discover how one does that and still gets a performance the user accepts at that degree of linearization. len From: Simon St.Laurent [mailto:simonstl@s...] 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
|