[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Best Practice - beyond schema
>An interesting best practice thread might be > >1. What CAN'T be handled with an authoritative transform? > "authoritative" meaning "as specified by the original (or agreed) schema author"? As in, the named authority. It might be any of a number of entities. Conceptually, it is the cited owner of the record of authority. One way to get the effect of locale is to cite the transform instead of the schema as authoritative over the local scope of effect. The schema is an input to that. >2. Given transforms, how much post-parse information really > needs a more powerful schema formalism? If so, when? >I'm sorry, I don't really understand how transforms effect the PSVI >requirement - can you elaborate? If a PSVI or as Rick said better, a Typed Infoset, has an XML form, isn't it possible to convert to that form by transformation? If not, no. >3. What requirements for a schema language should be posed for > any project and what should be explicit to a project? It > seems to me that we don't have many criteria for evaluating > these proposed mods and features for schema languages? >Some of these requirements may emerge during projects, I agree it would >be nice to list them for future use and better understanding. The problem then is that we are seeing schema languages being proposed for which we have no use cases that result in requirements that can be evaluated. How then does a developer or organization choose? How can one take their project requirements and use them to contrast and compare to the capabilities of a schema language? As in the trite but true scenario I outlined the other day, Step 3 (the recommendation from the technical team) vanishes into Step 4 (manager picks based on recommendations from inner peers). There is a sort of cluelessness there that means dumb luck rules the project thereafter. To ensure dumb luck has the best luck, the schema language ends up needing to be feature-rich and non-layered to cover as many dumb cases as possible. >>I don't find it compelling to have a means to validate or >>augment that can't be inspected and proven by readily >>available means if it has to cited normatively. That's >>the transparency requirement. But it also may just be my >>SGML Ludditism showing because I accept a lot of behind >>the scenes manipulation from my relational toolsets. >I think the effect of this utility works is obvious enough to count as >totally transparent. On the other hand more powerful tools might use the >same underlying technology and have equally open source, but eventually >the complexity of effect will take one to the other side of the >indeterminate "transparency v. opacity" boundary. What is unrecognizable is unknown and it varies by context. The context has to be the proof of effect where the proof is transparent. In other words, it can be black box but the proof must be clear as to why it proves the case. But my point is that I am being pristine about this technology because markup itself and XML specifically goes out of its way to get rid of layers that make it impossible to see into the box. If we put those back, we have to confess that things like Typed Infoset, PSVI, etc, are the way back into the machine, the realm of XML Systems, not XML. This isn't all bad but it is a step past XML 1.0 to be sure. >>>Flatten out one piece of the complexity carpet and darned >>>if another part doesn't ripple. Try to rehost an MS Access >>>app into Visual Foxpro and watch code disappear into >>>the more powerful but explicitly relational language >>>features of Fox. What goes on beneath the rug? We aren't >>>supposed to care if the results are provably the same. >>Shouldn't that be the case for the schema language processors? >Yes, let's hope layering leads to a more complementary outcome. I hope it leads to a more maintainable system where features can always be stripped away or added as needed. On the other hand, there are very good reasons for tools like Visual FoxPro that have powerful and specific features for a specific application, relational database system building, vs say Visual Basic that has features for connecting to a relational database. Not surprisingly, the relational aspects are easier in Fox, but the GUI aspects are harder. Exactly the reverse goes on in Visual Basic. Jumping between the two can be exasperating. I speculate that Typed Infosets which if pluggable become, Application Typed Infosets will offer the same dilemma: clarity in the specific application, obscurity with regards to general tasks. len
|
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
|