OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Elements vs. attributes was: Are people really using Iden

[ Lists Home | Date Index | Thread 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.

len

From: Owen Walcher [mailto:xpriori@owenwalcher.com]

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
this:

<address>
    <street />
    <city />
    <state />
    <zipCode />
    <country />
</address>

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:

<address country="us">
    <street />
    <city />
    <state />
     <zipCode />
</address>

for US address, and the the following for UK addresses:

<address country="uk">
   <buildingName />
   <street />
   <city />
   <postalCode />
</address>

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?




 

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

Copyright 2001 XML.org. This site is hosted by OASIS