LDraw.org Discussion Forums
[Thoughts wanted] Parts.xml - xml improvement on Part.lst - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Models and Parts (https://forums.ldraw.org/forum-18.html)
+--- Forum: Parts Authoring (https://forums.ldraw.org/forum-19.html)
+--- Thread: [Thoughts wanted] Parts.xml - xml improvement on Part.lst (/thread-8049.html)

Pages: 1 2 3 4 5


[Thoughts wanted] Parts.xml - xml improvement on Part.lst - Tim Gould - 2013-02-02

Hi All,

For a long time I've wanted there to be an .xml version of parts.lst containing not only the part and description, but also additional meta data. When Michael posted his fine looking LDFind today I had my final motivation to do something about it. Because a good Parts.xml would make searching so much easier.

As such LDMakeList 1.0 will make Parts.lst in the usual way, but will also make Parts.xml with a very simple format. I'd like some ideas of what should and shouldn't go into this format. Right now I'm wavering on 'License' for example.

So far each entry is as follows
Code:
<Part [Unofficial="1"] [Primitive="1"]>
<Number>XXXX.dat</Number>
<Description>Brick  7 x 19</Description>
[<License>GPL 4500.0</License>]
[<Category>Weird brick</Category>]
[<Keywords>this,brick,would,never,exist</Keywords>]
</Part>

where things in square brackets appear only when required.

I've attached an example.



Anyway, I welcome your thoughts on this.


Re: [Thoughts wanted] Parts.xml - xml improvement on Part.lst - Tim Gould - 2013-02-02

I should note that the other reason I like an .xml format is that it provides extra meta information to any LDraw program accessing the library. So e.g. LDFind could search straight from the .xml file, or a new editor could get meta information immediately from the .xml file.


Re: [Thoughts wanted] Parts.xml - xml improvement on Part.lst - Michael Heidemann - 2013-02-02

Thanks for mentioning my brand new tool LDFind.

The reason why I used xml for storing the data is, that the speed is much higher that I have done with my approach to store the necessary data.

I have also thought about using a complex structure to store the data, but I ended up with just a staight line in the xml file for one file.
By doing this I feel the speed is higher and if I browse with a text editor it is much easier to find the entries. Also the file is smaller Smile

If we do such a file (my attempt is nearly the same) all data from the file should be stored in that xml file. So I think about this file like combining all header data into a single file with a reference to the place where the file can be found for the specific data.


Re: [Thoughts wanted] Parts.xml - xml improvement on Part.lst - Tim Gould - 2013-02-03

I hadn't actually run LDFind yet (was busy coding). Now that I have tried I have found that it doesn't run on my machine.


Re: [Thoughts wanted] Parts.xml - xml improvement on Part.lst - Allen Smith - 2013-02-03

My XML part catalog file also includes a category database.

Something similar to this:
<Catalog>
<Category>
<name="Arch"/>
<Part>2145.dat</Part>
<Part>2339.dat</Part>
</Category>
<!-- More categories -->
</Catalog>

Although such a thing could just as easily be generated from the list of parts, and probably quickly too.

Allen


Re: [Thoughts wanted] Parts.xml - xml improvement on Part.lst - Tim Gould - 2013-02-03

Yeah my plan was simply to generate a file with the important inform for the parts ie. a direct replacement for parts.lst. It can then be played with by any other code Smile

As I'm not a Mac user, could you possible send me a copy of the .xml files you generate so I can check them out for consistency.

Tim


Re: [Thoughts wanted] Parts.xml - xml improvement on Part.lst - Steffen - 2013-02-03

I do not like this
Code:
<Part Primitive="1">
. A part is no primitive. I suggest to either use instead
Code:
<Primitive>
or
Code:
<File Primitive="1">
<File Part="1">



Re: [Thoughts wanted] Parts.xml - xml improvement on Part.lst - Tim Gould - 2013-02-03

Yes. Good idea. I will use <Part> or <Primitive>


[Thoughts wanted] UPDATE: Parts.xml - xml improvement on Part.lst - Tim Gould - 2013-02-03

Version II

Code:
<{Part|Primitive} [Unofficial="1"]>
<Number>XXXX.dat</Number>
<Description>Brick  7 x 19</Description>
<LDrawOrg>Part UPDATE 2099-2</LDrawOrg>
[<License>GPL 4500.0</License>]
<Category>Weird brick</Category>
[<Keywords>this,brick,would,never,exist</Keywords>]
[<Help>LEGO have really started getting weird with their new moulds</Help>]
[<History>TG 2083</History>]
[<BFC>Certify CW</BFC>]
</{Part|Primitive}>

where things in square brackets appear only when required and {A|B} means A or B.

The License presently does not appear

I've attached an example.


Re: [Thoughts wanted] UPDATE: Parts.xml - xml improvement on Part.lst - Michael Heidemann - 2013-02-03

Why do you split parts primitives?
There is an entry what kind of file it is. To use it double is waisting space IMHO.
Also if you would define all entries a attributes then you can save also a lot of space.

<PartEntry Number="XXXX.dat" Description="Brick 7 x 19" LDrawOrg="Part UPDATE 2099-2" License="GPL 4500.0" Category="Weird brick" Keywords="this, brick, would, never, exist" Help="LEGO have really started getting weird with their new moulds" History="TG 2083" BFC="Certify CW">

Additionally I would add FullPath, Author and Comments attribute. If we also add an "IsOfficial" attribute that can be true or false we can add unofficial files to this database.