XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] How to design XML to have broad utility and yet alsoenable 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/



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS