Open Stack

There are existing mappings for this, like JSONx, but I don't think that's the right approach.  You lose the benefits of having XML at that point -- no namespaces, etc.  What you need to find is a nice middle ground, where you get benefits from XML, but you don't have to deal with a lot of the subtleties. 

For example, you could lose the differences between attributes and elements in XML, that should make the mapping easier...

<servers xmlns="http://docs.openstack.org/nova/server">
   <name>...</name>
   <owner>...</owner>
   .
   .
</servers>

and you can do arrays like this...

<servers xmlns="http://docs.openstack.org/nova/server">
    <server>...</server>
    <server>...</server>
</servers>


XML folks don't think in terms of objects and arrays.  Also datatypes are typically  in the schema not in the document.

You have to have some rules in the JSON to make this work:

1.  There's a way of determining what the JSON object is.. by using the wrap approach (we do this now) or having a "type" attribute, or by some other means
2.  We don't allow spaces for object names etc so {"servers" ...} is okay but not {"     servers": ...} 

But these shouldn't be a big deal,

-jOrGe W.

On Jun 20, 2013, at 1:00 PM, Vishvananda Ishaya wrote:

> 
> On Jun 20, 2013, at 10:22 AM, Brant Knudson <blk at acm.org> wrote:
> 
>> How about a mapping of JSON concepts to XML like:
>> 
>> collections:
>> <object> <pair name="pair-name"> the-value </pair> ... </object>
>> <array> <element> the-value </element> ... </array>
>> 
>> values:
>> <string>text</string>
>> <true/>
>> <false/>
>> <null/>
>> <number>number</number>
>> 
>> This type of mapping would remove any ambiguities. Ambiguities and complexity are problems I've seen with the XML-JSON mapping in Keystone. Plus the fact that it's so not-XML would convince users to switch to JSON. With a simple mapping, I don't think it would be necessary to test all the interfaces for both XML and JSON, just test the mapping code.
> 
> +1 for something like this. JSON primary + autgenerated XML. I think the ideal version would be autogeneration of xml from jsonschema and some method for prettifying the xml representation via jsonschema tags. The jsonschema + tags approach is probably a bit further off (maybe for v4?), so having an auto conversion which is ugly but functional seems better than no XML support at all.
> 
> Vish
> 
>> 
>> 
>> 
>> On Thu, Jun 20, 2013 at 11:11 AM, Jorge Williams <jorge.williams at rackspace.com> wrote:
>> 
>> On Jun 20, 2013, at 10:51 AM, Russell Bryant wrote:
>> 
>> > On 06/20/2013 11:20 AM, Brian Elliott wrote:
>> >> On Jun 19, 2013, at 7:34 PM, Christopher Yeoh <cbkyeoh at gmail.com> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> Just wondering what people thought about how necessary it is to keep XML support for the Nova v3 API, given that if we want to drop it doing so during the v2->v3 transition is pretty much the ideal time to do so.
>> >>>
>> >>> The current plan is to keep it and is what we have been doing so far when porting extensions, but there are pretty obvious long term development and test savings if we only have one API format to support.
>> >>>
>> >>> Regards,
>> >>>
>> >>> Chris
>> >>>
>> >>
>> >> Can we support CORBA?
>> >>
>> >> No really, it'd be great to drop support for it while we can.
>> >
>> > I agree personally ... but this has come up before, and when polling the
>> > larger audience (and not just the dev list), there is still a large
>> > amount of demand for XML support (or at least that was my
>> > interpretation).  So, I think it should stay.
>> >
>> > I'm all for anything that makes supporting both easier.  It doesn't have
>> > to be the ideal XML representation.  If we wanted to adopt different
>> > formatting to make supporting it easier (automatic conversion from json
>> > in the code I guess), I'd be fine with that.
>> >
>> 
>> 
>> I agree, we can change the XML representation to make it easy to convert between XML and JSON.  If I could go back in time, that would definitely be something I would do different.  3.0 gives us an opportunity to start over in that regard.    Extensions may still be "tricky" because you still want to use namespaces, but having a simpler mapping may simplify the process of supporting both.
>> 
>> -jOrGe W.
>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev