RE: [xml-dev] How to design XML to have broad utility and yet also enable efficient application processing?

From
Simon St.Laurent <>
To
Date
2013-11-21T20:42:09Z
ID
<>
Thread
RE: [xml-dev] How to design XML to have broad utility and yet also enable efficient application processing?
> The war between complex and simple and re-use, leads  to componentization.
> Data Model components are in effect the sub-routines of data exchange. One
> big model or 10 component models.it is possible that the 10 components may
> be less efficient than the One True Model, but it is certain that when
> things change, it will be easier to drop one component, and to define and
> add another to the mix.
>
> But of course, solving *that* or even better avoiding that evolutionary
> complexity leads back to namespaces, much despised on this list.

I'm not convinced it actually _has_ to lead back to namespaces.

There are other ways to identify "this comes from a certain context" than
gluing URIs to element and attribute names.

Transformations and metadata aren't that complicated.  (HTML5 Web
Components, for example, don't require namespaces.) Those approaches don't
try to solve the whole problem at one shot, but that seems to me like a
feature not a bug.

However much this list may despise them, namespaces are pretty well baked
into the political landscape of XML standards development.  I doubt
they'll go away in that context.

Thanks,
Simon St.Laurent
http://simonstl.com/