Celestia Forums

Anybody interested in working on an XML format for .scc-file-like information to be published as a planetary definition standard, please contact SpaceGear.Org.

dtessman wrote:Anybody interested in working on an XML format for .scc-file-like information to be published as a planetary definition standard, please contact SpaceGear.Org.

I've already got an XML format for Celestia . . . The XML parser isn't included with the Celestia distribution right now because I haven't had a chance to get libxml support working across all platforms (actually, the problem has more to do with the various incompatible versions of libxml installed on Linux machines.) Here's a sample .ssc file:



How does this look? I know bruckner expressed some interest in an XML format . . . how interested is everyone else?

--Chris

chris wrote:I've already got an XML format for Celestia . . . The XML parser isn't included with the Celestia distribution right now because I haven't had a chance to get libxml support working across all platforms (actually, the problem has more to do with the various incompatible versions of libxml installed on Linux machines.) Here's a sample .ssc file:

Have you looked at expat? (http://expat.sourceforge.net/). It is what I used for CStarsConv. It usually loads as a DLL, but I converted it to a standard library. I included it in the CStarsConv source.

chris wrote:How does this look?...

Look'n good! I would suggest the use of ISO standard element and attribute naming conventions.

Elements name are in UpperCamelCase
Attributes are in lowerCamelCase
No Dashes, Periods, or Underscores
Limit use of abbreviations and acronyms
If acronyms are used then they should be all upper case

I would like to work together with you on getting something like this published as a standard. Please let me know if this is something you would be willing to partner on.

---
Dave
SpaceGear.Org
Open Standards for Space Flight Simulation(tm)

Well, will XML have any advantage over the current system? In particular, it doesn't look as if it'll be easy to code...

Sum0 wrote:Well, will XML have any advantage over the current system? In particular, it doesn't look as if it'll be easy to code...

If you use a parser library, XML is actually easier to code. There is also a formal descriptive language (XML Schema), so there is no abiguity as to what goes where and what is allowed. There is a growing "instant familiarity" factor because it is a standard. There is an ever growing base of tools for the XML creator, parser, and designer. Especially scripting based translation tools, that allow XML to be tweaked into all sorts of things, including HTML pages. Basically you are leveraging the work of lots of other coders by using XML.

My favorite part is that because XML is standard, the resulting file format (schema) can be standardized and then easily merged into larger networks of interelated documents.

Standardization means that a program such as Jim Burrows's StarGen could be tweaked once to produce a star system file that can be used directly by Celestia, be the part of SGO's Star System Definition standard, be used by a program like Unistellar's E-10 project, etc.

-----
Dave
Spacegear.Org
Open Standards for Space Flight Simulation(tm)

I have been working with a few people over on the VegaStrike Project http://sourceforge.net/projects/vegastrike/ trying to come up with a standard that is XML compatible and easy to read. This is what we have come up with. It is still being developed, but I would like to see if we can get both projects to use the same files for the data.


If you haven’t guessed I’m trying to group like fields into sub categories. Lets see if we can work together to come up with a single standard.

-Matt-

Matt wrote:Lets see if we can work together to come up with a single standard.

Matt,

Sounds good. Send whatever you got in the way of documentation over my way (dtessman@zelestra.com) and lets start a dialog on this. I would like to help where I can.

--------------
Dave
SpaceGear.Org
Open Standards for Space Flight Simulation(tm)

Anonymous wrote:I have been working with a few people over on the VegaStrike Project http://sourceforge.net/projects/vegastrike/ trying to come up with a standard that is XML compatible and easy to read. This is what we have come up with. It is still being developed, but I would like to see if we can get both projects to use the same files for the data.

What the hell...the font on that site are all squares?? Whats this project anyways?

Here is a small sample piece of the StarSystemDefinition format (work in progress).
Numbers are not representative and lots of stuff yet to be defined.


----
Dave
SpaceGear.Org
Open Standards for Space Flight Simulation(tm)

chris wrote:How does this look? ...

Chris,

Unit designations should be separate from the data and putting the data as attributes prevents qualifiers from being put on the data.

So


Prevents adding metadata to the value such as a units designation.
by using <Period>02.408</Period> you can do this:
<Period unit="year">0.2408</Period>
or
<Period unit="day">87.94</Period>

Thats why Name is pulled out as an element in the Star System Registry. So that one could eventually add a locale.
<Name locale="Klingon">Garnash</Name>

Please check out
http://www.spacegear.org/publications/xmlschemastandards/
For a (very) brief word on Elements vs. Attributes, etc.

dtessman wrote:Prevents adding metadata to the value such as a units designation.
by using <Period>02.408</Period> you can do this:
<Period unit="year">0.2408</Period>
or
<Period unit="days">87.94</Period>

Sounds reasonable, though the XML format is getting quite verbose . . . I suppose that's not such a terrible thing though. What tools do you use to avoid having to hand edit the files?

My main concern is that Celestia's planet description contains a lot of fields for rather ad hoc visual decoration (the haze stuff comes to mind.) I suppose these could all go inside a render element or something, to distinguish them from the physical data. Anyhow, I'll be looking at this a lot more seriously once 1.2.5 is done.

--Chris

Chris,

You should check out XML Spy Suite at http://www.xmlspy.com. It's a pretty good XML editing suite. It allows you to view an XML document in a collapsible tree format. Very helpful for those "verbose" XML files. Keep in mind that XML is meant to be more descriptive than pretty.

- a b i o g e n e s i s -

chris wrote:Sounds reasonable, though the XML format is getting quite verbose . . . I suppose that's not such a terrible thing though. What tools do you use to avoid having to hand edit the files?

Yes, XML is verbose by design.

W3C wrote:4. XML is verbose by design
From: http://www.w3.org/XML/1999/XML-in-10-points

The only place where I said enough is enough and used a lot of short abbreviations was the Star System Registry (SSR). With 100,000 stars, every ten characters adds a meg! It does compress nicely however. The stars.dat database converted to SSR winds up ballooning to about 10 Meg. However the it gets compressed down to about the size of stars.dat again (2 Meg) when compressed. An example of stars.dat as an SSR is located at http://www.zelestra.com/ssr.xml.gz. If was created with CStarsConv. The SSR schema is located at: http://www.spacegear.org/schemas/. Its purpose is to be an implementation independent import/export format of star system coordinates, so it is not intended to be permanently stored on the client anyway.

I usually hand-edit these documents or use specific parser programs like CStarsConv. I am most often putting together examples for design work so hand cranking is the norm. I have seen XMLSpy, but have not actually used it, I will have to take a serious look at it soon.