ANNOUNCEMENT - The community will be down for maintenace this Thursday August 13 from 12:00 AM PT to 02:00 AM PT. As a precaution save your work.
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2358
Views
9
Helpful
17
Replies
Highlighted
Contributor

Re: AXL vendorConfig

Thanks I never really completed this, but I got as far as building one complete xsd from all the files, including default values and some optimizing for redundant element types. My goal was a xsd with venetian blind design that contains all the phones. I still have to unroll some encapsulated types but I am almost there. There is a lot of redundancy in the type definitions in the vendorConfig files. In order to create pretty code I simply collapsed those that were functionally the same into one type that could be reused. I am well aware of that it might break in the future, but with all that is broken in the vendorConfig already I rather have simple code than 58 redundant classes that does exactly the same thing. Something more interesting (don't remember what...) came in between and I never finished this though.

Highlighted
Beginner

Re: AXL vendorConfig

Stumbled across this. Thanks! Weird how you cannot use zeep for the vendor Configs using the same data structure as the rest and you have to pass the data via XML? 

Highlighted
Contributor

Re: AXL vendorConfig

Yes, the vendorConfig is an xml-in-xml thingy with a completely different (non-documented) schema. Probably due to different business units form CUCM vs IP Phones within Cisco. Don't know about Zeep, but theoretically you should be able to map the xsd built according to the instructions in my previous posts to the vendorConfig's "any" field, so you don't have to craft the xml by hand.