Cart
[Home] [By Thread] [By Date] [Recent Entries]
> > Although I believe that there might be a valid case here, there are some > serious implications to this construct - one that springs imediately to my > mind is the issue of content equality. I.e. if you using a construct like > the above you are saying that the content of the xhtml:body and my:body > elements are the same - at least in valid documents. If that's the case > why > don't you just use the xhtml:body in your my-schema? That's a good point. Only two good arguments I can think of: 1) Equivalently named and contented <g> elements may not have equivalent meanings in both namespaces. <xhmtl:body> is format indicator, whereas <my:body> could describe, well, my body. Different namespaces, different meanings. 2) No prior knowledge of future intent. When I defined the element <my:body>, I had no knowledge or intention of seeing that content formatted in xhtml. Somebody, somewhere later decides that the content I provided is useful (as is) for the type of representation they want to present. I think a fair response to those two arguments is to ask how often an element, whose content is designed for one purpose, as a same-named equivalent in another namespace context that, coincidently, has a definition compatible with the former? It seems like a bit of a stretch upon further reflection. No point in solving purely theoretical problems.
|
