Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Schemas: Best Practices
 "Roger L. Costello" wrote: > My response to this. I wonder if you would even want to write tools for > Chameleon components? Since Chameleon components are independent of > context (namespace) then it makes me question whether you would want to > write tools for such context-independent components? It seems to me > that the tools should be written for the schemas which incorporate the > Chameleon components. What do you think? In spite of the fact that I raised the objection, I've wondered about this myself. However, I'll give two examples -- one trivial, the other non-trivial. 1) Schema A defines an address schema and code to store addresses in a database. Schema B defines the format of a bug report and code to store that in a database. I want to create an application where users can report bugs over the Web with XML as the data transport. I would like contact information for the people who report bugs so I can ask them later if they'd like to be in a beta program. I grab the schemas A and B and code A and B, put them together, and I'm done. 2) XML is starting to see quite a bit of use as a way to serialize object data. Two common pieces of reusable code are COM objects and JavaBeans. Since each object has its own properties, it will have its own code to marshall/unmarshall its data. It is highly likely that property names will collide among such objects -- Name, Help, etc. It is even possible that the object names themselves will collide. Now imagine that I use some of these controls to build a Web-based game or chat room software or something similar that uses XML as a data transport, where the data for all the objects is placed in a single document. First, I want to reuse the marshalling code so that building my application is just a matter of slapping the components on a form and adding a bit of control code. (OK, that's what the marketing people say.) Second, I need namespaces to tell me which name goes with which piece of marshalling code. > How would the tool T be able to distinguish between the Chameleon > component A and the local A? > > One simple solution is that when you create Chameleon components assign > them a global unique id (a GUID). The XML Schema spec allows you to add > an attribute, id, to all element, attribute, complexType, and simpleType > components. This id attribute can be used by a tool to "locate" a > Chameleon component, regardless of what "face" (namespace) it currently > wears. That is, the tool opens up an instance document using DOM, and > the DOM API will provide the tool access to the id value for all > components in the instance document. This works and takes an interesting tack -- it not only separates names and IDs, it obviates the need for namespaces altogether. Then again, I'm not sure I want to see stylesheets with GUIDs in them... (Stylesheets are another thing that identifies elements by name and are reusable. For example, for each element type in your schema, you could define a single rule for how to map it to HTML. The rule would follow the element type from schema to schema. This might not work across corporations, due to different ideas about what a Web page should look like, but it might work very well inside a single corporation with a consistent Web look and feel.) -- Ronald Bourret Programming, Writing, and Training XML, Databases, and Schemas http://www.rpbourret.com 
|
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
|
|||||||||
