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] Syntax + object model

[ Lists Home | Date Index | Thread Index ]

> From: Bill de hÓra [mailto:bill.dehora@propylon.com]

> > Hashmaps, arrays, red-black trees, dictionaries, etc. all 
> operate on pretty
> > much the same principles (at least in the OO languages) 
> regardless of the
> > actual language they're implemented in.  
> 
> Oh sure, but have you tried moving them around (even only amongst OO 
> languages)? Perhaps this is ungenerous, but sharing basic data 
> structures seems to be something of a continuing research 
> project in WS.

The point is not to move the implementations around, but to describe a set
of behaviors to be )(optionally) implemented.  Nobody's talking about
sharing the data structures, but sharing the serialization of those data
structures through XML, and not losing the intent of those structures in the
process.

Basically, it's adding a bit extra information to the serialization that can
potentially drive automation in a more efficient way.  This is as opposed to
a DOM, or fine-grained and inefficient object instances. It does not
presribe a language, and implementation, or even specifics of the internal
representation. It doesn't even prohibit alternate internal structure more
amenable to the consumer's processes.  All it does is avoid the loss of
potentially useful information in regards to how the originator found the
best way to internally represent the data that was serialized.  

Example:

<a>
   <b key="233">"foo"</b>
   <b key="245">"bar"</b>
   <b key="335">"baz"</b>
</a>

Normally, if you're consuming this data and hand-coding the classes, you'll
have enough understanding of the data to write and efficient structure,
whether it's and array, dictionary, or hashmap.  But what if you want to
generate code?  Not enough information here.   

The problem with code generation utilities that I've used is that they will
generate lowest common denominator type data structures.  You can modify
what's generated through mapping files, but these don't seem to support
higher-level type data structures (it's more atom-to-atom fine grained
mapping that's supported).

I think if you add information to the serialization that the above
informatio was generated from, say, a hashmap, then you've added some pretty
useful processing information (and actually documented some semantics as
well):

<!-- using Bad Boy non-XML syntax for clarity -->

<a {struct="hashmap" keyval="key" keytype="int" target="text-node"}>
   <b key="233">"foo"</b>
   <b key="245">"bar"</b>
   <b key="335">"baz"</b>
</a>
   
Now this is useful information for even non-OO representations, such as SQL
tables.  This doesn't even describe an interface that need to be conformed
to.



> 
> Bill de hÓra
> --
> Propylon
> www.propylon.com
> 
> 




 

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

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