xml-dev - Re: XML Schemas: Best Practices

[Ronald Bourret <rpbourret@rpbourret.com>]

"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