Lists Home |
Date Index |
On Dec 13, 2004, at 16:39, Rich Salz wrote:
>> I see. So generally speaking, explicitly "normalizing" the data is
>> mostly beneficial for the processing tools?
> Don't forget the biggest (err) tool of all, however, the humans who
> have to work with the data!
I was waiting for this one... ;)
> Doesn't it make more sense to model a dictionary as a set of entries,
> and an entry is a set of key/value pairs?
As far as explicitly spelling-out the structural information of a
dictionary element, then yes... on the other hand, I'm not quiet sure
if such normalization is undeniably beneficial to "wetware" at the end
of the day :o) ... arguably this could be a question of taste...
> When you think "set of" in XML, think "child element"
Good rule. I will keep that in mind :)
> FWIW, here's what I'd do
> <key type="...">blabla</key>
> <value type="...">foo foo</value>
Interestingly enough, the above is pretty much what I started with...
however, my atavistic dislike of angle brackets took over and I ended
up removing all the structural information specific to a dictionary:
> As for e/entry and key/k value/v, that's your choice. I'd add a type
> attribute (leaving it out defaults to "string" probably) so that if
> you build xml<->data tools you know what you've got. I'd use type as
> an attribute, since it is meta-data information about the content.
I'm not sure if I follow this line of reasoning... after all, the
"raison d'Ítre" of an element is to provide meta-data about the
content... should attributes be viewed as meta-data about the content
or the element itself? Traditional schemes (eg XHTML) use element
attributes as, well, attributes (eg parameters to the element).
Usually, an attribute doesn't define the element content. Or am I
What's the benefit of using an element attribute to define the type
versus using a different element altogether?