Attributes, Was Top Down vs. Bottom up

[Phillip Hallam-Baker <pbaker@verisign.com>]

Lets leave the Toppish or Bottomish argument for a moment.

Dave mentioned attributes. From the conference call I got
a feeling that there was support for an 'attributes with
values' type of construct, e.g.:

<Object>
   <Attribute>
       <Tag>http://ids.bankcartel.com/2001-03-23/credit-rating</Tag>
       <Value>1000</Value>
   </Attribute>
</Object>

The reason I went for the URI tag approach was simply that 
I prefer strawmen that have the least typing. It is better to
have people wanting to put features in than take them out.

One could go futher and consider the case in which a single
URI might introduce many tag value pairs, i.e.

<Object>
   <Attributes>
       <Field>http://ids.bankcartel.com/2001-03-23/data</Field>
       <Pair>
           <Tag>credit-rating</Tag>
           <Value>1000</Value>
       </Pair>
       <Pair>
           <Tag>credit-rating-currency</Tag>
           <Value>USD</Value>
       </Pair>
   </Attributes>
</Object>

However I think that such a system looks ugly and since there
is no means of enforcing type constraints is yucky. I would prefer:

<Object>
   <CreditData xmlns="cd:http://ids.bankcartel.com/2001-03-23/data">
      <cd:Rating>1000</cd:Rating>
      <cd:Currency>USD</cd:Currency>
   </CreditData>
</Object>

In other words where there is a demand for a lot of custom data 
we should encourage applications to implement their own schema
and slot the additional data in.


> Cool.  Thanks for the education.  I've sometimes thought 
> about trying to go
> back to school and learn more formal stuff.  But I think my 
> brain is too old
> for the math.  The closest I can handle is "Proof".

I gave up when it was clear that to do any more I would have to 
learn category theory. Same reason I gave up on Theoretical
Physics when I read the opening paragraph of Stephen Hwaking's
othe book 'Take a Hausdorfian manifolds with Lipsig signature ..'

The conclusion of my PhD thesis was that to address real world
problems with formal methods it was necessary to develop a
computing language specific to each problem, then generate a 
code synthesiser that spat out both the code and the proof of
the code together.


		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

Phillip Hallam-Baker (E-mail).vcf