Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XML Schemas: Best Practices
 Short answer: No recommendation. Practice must suit requirement. ******************************************** Long answer: It depends as I said before on whether the type maintenance is needed and will be expressed in the schema say, vs constraints expressed in an application rule. IOW, the question is really, when does one need abstract types? Obviously, abstract types means someone has been negotiating an abstraction (a compression of representation). If the hard requirement is for variable content from non-communicating sources, you are down to the OR group (doesn't care - it groups, it doesn't compress the representation). Aside from compression, you have to ask yourself what you are going to do with the schema over time. IMO, a Best Practice can't be divorced from the rules of the environment of the practice of combining sources. My experience heretofore with SGML was that systems needing DTDs needed agreements apriori. That is what makes them tough to build; the politics of agreement, but this was before XML became a messaging format. In SGML, it was a contract among companies or customers to enhance lifecycles for documents. That is the real reason only the bigGuys did it. Few others needed it enough to pay for it. On the other hand, when I've had to o initialize an authoring system with it (eg, think ArborText or Softquad editors that are DTD enabled) o aggregate in a stylesheet enabled player which got rid of the need to downtranslate (eg, to HTML) and there are multiple, equal authorities controlling the content, I used the OR group to switch sets in and out. In an situation with equal probabilties, the rule of choice is an external authority/system (eg, the workflow system rules the content of the document). Using the OR, a DTD controls a set of multiple document types that share sub-trees. The choice of type depends on the what content type is requested. I did this both for US Navy Work Package systems (CASS) and US Army DTDs for IADS because each of the document families was as you say, under different controlling authorities but the actual document had to be authored as if it were one document. The only reason to combine them was their contents are shared in the target player (IADS in the second case) which was stylesheet-enabled and frame targeted, or the authoring tool used by one group all the time (CASS). In other words, we were not downtranslating; we aggregated. That is quite a different issue from using a schema as a sort of object hierarchy declaration or to feed a transform. In short, remember that a schema is a formal description and the "bestness" of the practice has to be defined in terms of the environment of the requirement of use or the local rules of the thing described. We have multiple means because we have multiple overlapping but distinct requirements. BTW: I've never cared for entity based modularization. It is ugly to teach, ugly to use, and ultimately, it seems, only helps the DTD maintainer keep up with abstract grouping names. I prefered switching tags that at least make the GUI look more sensible by clearly showing it was a choice, not an object. PE modularization has always looked like a hack to me; useful but asserting the DTD is a better description than it actually is. I am in the minority on that position because switch tags result in crud in the file which the semantic or style processor has to ignore. Some early systems used to stick a non-displaying but format affective (space, line end, etc) in there anyway and the rules for the formatting stylesheet could get ugly keeping that out. On the other hand, say using XPath, a switch tag can be convenience. We ended up with them in X3D to make the multiple encoding madness easier to live with, thus <children> is in there although one wishes it weren't. Now that schemas enables abstract types (X3D is an abstract node language from the get go), we can make those go away. Len http://www.mp3.com/LenBullard Ekam sat.h, Vipraah bahudhaa vadanti. Daamyata. Datta. Dayadhvam.h -----Original Message----- From: Roger L. Costello [mailto:costello@m...] Of the 3 methods, which one would you recommend for Best Practice Curt? Len, what's your recommendation? /Roger 
|
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
|
|||||||||
