Ooh!

[kaladorn]

It should have read

<planet uwp="C887798-4" hex="2410" sectorname="Spinward Marches" sectorfile="sm.gal" sectormap="sm.gif">

The short form was there just because that's how the sector file is named. But you should have the 'printable name' for at a glance viewing too. And identifying the files involved is just a good plan too.

 

[tjoneslo]

Originally posted by robject:
<planet> can be exploded if you prefer, but frankly I find it more readable without all that scattershot text in between.
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;"><planet name="foo" starport="A" size="4000" atmosphere="4" hydrosphere="6" population="4000000" government="6" lawlevel="8" tl="12"></pre>

[/quote]Actually one of the reasons to use all the scattershot text is to allow the use of a Cascading Style Sheet (which displays only element values not attributes) and allows another view of the data.

 

[kaladorn]

A fair comment. Mind you, if you have to expand every branch to see the minimally necessary things to sort through a sector file for the planet you want, that's not good either.

 

[tjoneslo]

This depends entirely upon how you expect the user to see the data. Reading (and writing) the raw xml? Even a subsector's worth is a complete pain to deal with, and I can't see handing sectors worth of data that way. Even with a XML Tree browser like IE6.

If you have an xml viewer capable of handing the XML+CSS you can make the data a little more compact (ie, no more xml tags).

I'll bet you could come up with a really neat graphic display system using XML+CSS and javascript. And now we're onto the real programming languages, where XML becomes a data storage format, never seen by the user.

 

[robject]

Good point, of course. But then, if the app's done right, the storage medium is wrapped in an API?

 

[robject]

Or, even better, the API looks like structures in that language.

 

[kaladorn]

Originally posted by tjoneslo:
This depends entirely upon how you expect the user to see the data. Reading (and writing) the raw xml? Even a subsector's worth is a complete pain to deal with, and I can't see handing sectors worth of data that way. Even with a XML Tree browser like IE6.

If you have an xml viewer capable of handing the XML+CSS you can make the data a little more compact (ie, no more xml tags).

I'll bet you could come up with a really neat graphic display system using XML+CSS and javascript. And now we're onto the real programming languages, where XML becomes a data storage format, never seen by the user.

I'm afraid we'll diverge philosophically here.

XML is *meant* to be human readable. As a machine-only data storage format, it is grossly inefficient.

And FYI, I *do* look at sectors full of data just as you describe no one wanting to. I use IE/Firebird or other similar tools. I could fire up various other XML tools I have, but why bother if I do not need to?

The point of using a format that is generic is to NOT superimpose ones personal opinions of how things should be viewed on the user. What you think is ludicrous, others may think is vital. So you try to accomodate all configurations, IMO.

So, I would not be in favour of anything that makes the format less usable to the essentially eyes-on human.