first comment on the schema at https://github.com/FUNcube/SatInfoServi ... ellite.xml:The SATCAT number is called NasaID. Not sure where this originated, but NASA has nothing to do with it. it was NORAD before, and now its more universally called SatCat.

<tns:LaunchingSite> should be LaunchSite

I think beacons should be telemetry or beaconsbeacons should be reserved for identification I guess... or eliminated completely

<tns:Mode>FM</tns:Mode> should become Modulation, and like mentioned before we should also include framing to be flexible. not sure what to do with FEC...

basic should be something like index or identification?Satellites should only be uniquely identified by catalog number. If a satellite has not been assigned a catalog number then it should probably be in a separate database. So catalog is mandatory.Their can be more than one name.Add an optional free-format text field for a description of the satellite.

EnumerationsFields such as modulation, protocol and coding should only contain values from agreed lists.

And do you have any examples of satellites that are not in the catalog? I would say they should all be in, except in LEOPS right after launch. But in this case, normally everyone takes 99999U. This is a problem for multiple satellites on one launch, so we should have a way of indicating that something is not in the catalog yet. But apart from that, are you aware of something without SATCAT number?

Also, in LEOPS, sometimes satellites are hopping between catalog numbers.

I already had in my initial E-mail the need for the status options. One more flag to put into the transponders might be IlluminationRequired: does the satellite work in the dark or not (AO-7, Delfi-C3)Doing this per transponder gives more flexibility.

Some feedback, opinion:* i cant see the need for the extra wrappers: aliases, beacons, transponders.* frequency should not be abbreviated.* frequency should be in Hz.* state would be nice as an atrribute.* how about centerfreq, bandwidth instead of upper/lower bounds.* how about giving a transponder an attribute inverting='true/false'

My next attempt, i'm struggling how to model a AO-40 matrix system, a proper, but less simple way for clients is to use xsd:id for the up and downlink and refer (xsd:idref) to them in transponder elements.