Lists Home |
Date Index |
Which is the beginning of the 'what are atts good for?, they are
good for metadata', permathread.
If one builds a dynamic assembly tool, one is often switching on
metadata. One can do the same thing with an OR group but the means
don't matter as long as one understands that the range of variants
is scoped to the contexts of the users. What happens:
1. Each user situation/context is evolving semi-independently so it
is a good idea to encapsulate the metadata separately. If
evolution in a context breaks out of the context into a higher
level component, the system objective for that component is not
independent. That is, you have a hidden coupler.
2. There is a performance hit for that step. That is ok.
Network effect takes over and is more important than the
performance of a single node.
3. This approach enables the rules to be adjusted just-in-time
based on exceptions as encountered. All exceptions are not errors.
4. Current use cases (a la XP) enable you to work out just
how inclusive/exclusive the boundaries are 'today'. The
exceptions cause boundary expansion.
5. Systems that expand their boundaries tend to collapse
eventually if the core user(s) of the service resources does not
use as little of them as possible (see Roman history) and
that is why loose coupling, coarse transactions, and rich clients
might be used to load balance the system. Caveat vendor.
Application builders in the MS world should take a hard
look at the application blocks concept, which are moreorless
how MS does open source.
From: Owen Walcher [mailto:firstname.lastname@example.org]
My use of attributes is only as needed to "scope" one or more elements with
a variant theme. Whereas element laden folks might write something like
Or the attribute laden result (to save space on the wire, presumably):
<address street = "714 my Street" city="my City" state="my State"
zipcode="00666" country="us" />
Which is a rigid (and USA is the only address type - how arrogant)
structure. Probably one of those IT folks who wrote the schema while their
business analyst was getting requirements.
But the flexibility of XML is that it can be heterogenous. . . and how to
understand when you will get what structure is the purpose of attributes. .
. so the more context sensitive XML modeler (who understands the
requirements first) might use:
for US address, and the the following for UK addresses:
I am not aware of a way to use Schema to enforce a substructure based on a
value in an attribute, but from the short look at CAM that I have done, this
seems to be exactly what it was designed to do. . . combine snippets of
variants together into a complete document that is very context aware.
David, did I get that right?