Cart
[Home] [By Thread] [By Date] [Recent Entries]
> ... AFs will be the rule, rather than the exception. AFs are, quite > simply, the object-oriented way of supporting reliable, vendor-neutral > information interchange. >[...] > AFs are all about hijacking arbitrary models of interchangeable > information, using such models in an unbounded number of contexts, > specializing them in validatable ways, mixing them together in > arbitrary ways, and supporting them via re-usable engines. I do not understand - I do *not* see AFs as "object oriented" in the least. It seems like a great "hack" enabled by hijacking DTDs. The more I read about it, the more convinced I became that AFs are indeed hacks. All the renaming attributes for the architecture name, attribute names, and attribute values, along with a recommendation to turn auto-associate off by default, point to a lack of a proper hierarchical namespace to avoid the consistent need to rename things because everything eventually collides in a flat namespace. That said, I read a lot of responses which basically shot down namespaces as unnecessarily complex. Why? I think the renaming one has to do with AF is unnecessarily complex. Agreed, namespaces alone don't solve the problem - namespaces try to behave like mathematical partitions, but as math profs claim "mathematics is not real-life!" > I often urge people who are interested in learning more about AFs to > read chapters 9-11 of David Megginson's excellent book: I have, in fact, read David's excellent discussion on AFs in this book. However, I fail to feel as optimistic about AFs as you; I'm wondering if there's a key point that I'm missing. > > The only reason why the AF framework wasn't used to do the job of > > namespaces (and yes, we thought about it a lot) is that the syntax > > for AF-ing attributes is ugly and complicated. I agree (above). I think AF's notions deserve a simpler syntax instead of the convoluted way in which it twists around existing schema formalisms. /David *************************************************************************** This is xml-dev, the mailing list for XML developers. To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/threads.html ***************************************************************************
|
