LDraw.org Discussion Forums
Introducing a second HL library? - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: General (https://forums.ldraw.org/forum-12.html)
+--- Forum: Official File Specifications/Standards (https://forums.ldraw.org/forum-32.html)
+--- Thread: Introducing a second HL library? (/thread-14432.html)

Pages: 1 2 3 4 5 6


Re: Introducing a second HL library? - Chris Dee - 2014-11-14

+1


Re: Introducing a second HL library? - Nicola - 2014-11-14

what about json instead of xml? same complexity to use, much smaller and much easier to read for human


Re: Introducing a second HL library? - Nicholas Zurn - 2014-11-14

It probably wouldn't hurt to have another version of all of the parts in the library in a format that is easily used in other programs and can be converted to other files successfully.


The mechanical side of me wishes there were CSG files for all of the parts.


Re: Introducing a second HL library? - Steffen - 2014-11-14

XML to me always appeared too overheading. Example: Pure XML for a quad would be:
Code:
<quad>
<color>16</color>
<vertex><x>1</x><y>2</y><z>3</z></vertex>
<vertex><x>4</x><y>5</y><z>6</z></vertex>
<vertex><x>7</x><y>8</y><z>9</z></vertex>
<vertex><x>10</x><y>11</y><z>12</z></vertex>
</quad>
If you want to make this more compact, you could go for something like this:
Code:
<quad>
<color>16</color>
<vertex>1 2 3</vertex>
<vertex>4 5 6</vertex>
<vertex>7 8 9</vertex>
<vertex>10 11 12</vertex>
</quad>
But to be honest: this is no longer pure XML. It is custom strings embedded into XML.
You still need to parse the strings. If you accept that, then you also must accept this,
which takes the principle 1 step further:
Code:
<quad>
<color>16</color>
<coordinates>
1 2 3
4 5 6
7 8 9
10 11 12
</coordinates>
</quad>
And even 1 step further:
Code:
<quad>16 1 2 3 4 5 6 7 8 9 10 11 12</quad>
Then you finally land at the current LDRAW format, which simply encodes <quad>...</quad> by the leading "4":
Code:
4 16 1 2 3 4 5 6 7 8 9 10 11 12
I write this to argument against XML. I have to deal with it a lot elsewhere, and despite the fact that parsers
for it exist a lot etc. pp., its syntax overhead always is ineffective and annoying.
JSON would be something much better IMHO. Parsers for it exist as well a lot.


Re: Introducing a second HL library? - Steffen - 2014-11-14

Nicola Wrote:About input problems, i think a program should be robust enought not to crash and report any error, but should never try to "autofix" things. HTML parsers of the previous decade showed this very clearly: the first browsers tried to autocorrect erratic html, and what they caused was more erratic html being created
I fully agree with you in this aspect. Programs need to be robust against rubbish, but should ignore it.
Otherwise people create more and more rubbish and are not aware of it. HTML is the exact example how things went mad.
Thanks a lot for pointing this out.

Regarding the LDRAW file format simplicity, I would like to answer, YES, I still regard LDRAW file format "simple":
It exactly IS what you claimed, i.e, just 3D vertices and color. It just has added tiny, tiny additions to it:
(a) BFC
(b) conditional lines
© inclusion of other files
Later,
(d) textures
were added. But (a)+© are trivial. (b) is a bit tricky and un-conventional but can programmatically done.
However, yes, I agree that some things like normals, connectivity info etc. is missing, but I would
still name the current format "simple". I would prefer to extend it to support normals and connectivity.
Not to replace it. It should be simple and easy to add those 2 syntax elements downwards-compatibly.


Re: Introducing a second HL library? - Nicola - 2014-11-14

Steffen Wrote:XML to me always appeared too overheading.

..


I write this to argument against XML. I have to deal with it a lot elsewhere, and despite the fact that parsers
for it exist a lot etc. pp., its syntax overhead always is ineffective and annoying.
JSON would be something much better IMHO. Parsers for it exist as well a lot.

I too have to deal with it daily at work Smile Here's an example of how a 3d geometry can be expressed in json (just an example, we can put whatever format of course):


Code:
{
    "metadata": {
        "version": 3.1,
        "type": "geometry",
        "generator": "GeometryExporter"
    },
    "vertices": [50,50,50,...],
    "normals": [1,0,0,...],
    "uvs": [[0,1,...]],
    "faces": [56,0,2,1,0,1,2,0,0,0,0,...]
}

(taken from here)

Boh machine and human readable. JSON can take advantage of array definitions which XML has not.


Re: Introducing a second HL library? - Santeri Piippo - 2014-11-14

+1 to JSON. I was going to suggest it myself. Though the syntax is awfully unforgiving...


Re: Introducing a second HL library? - Steffen - 2014-11-14

yes, I sometimes found it much easier to model parts directly in POVRay using CSG than in LDRAW, sigh......., that's true......


Sergio Reano passed away - Steffen - 2014-11-14

Oh, I hear this terrible news here the first time - what a loss!
This makes me so sad!

Just found a post about it at Eurobricks...
http://www.eurobricks.com/forum/index.php?showtopic=100887


Re: Introducing a second HL library? - Mario Pascucci - 2014-11-15

XML can be more compact if you use "attributes". To follow your example for a quad:
Code:
<quad color="4" normal="xn,yn,zn" v1="x1,y1,z1" v2="x2,y2,z2" v3="x3,y3,z3" v4="x4,y4,z4" />

You can omit attributes, or use combination, if document definition permits it:
Code:
<!-- a quad without normal and custom color with alpha -->
<quad argbcolor="c080ff80" v1="x1,y1,z1" v2="x2,y2,z2" v3="x3,y3,z3" v4="x4,y4,z4" />

It is valid XML and it isn't too "verbose".
Consider that you can automate transformation using stylesheet (XSL) and syntax checking using tools like XMLlint (verify an XML file against its XSD)

BTW, any format can be accettable, if permits easy syntax checking and well-supported parsing in many programming languages.

Mario