Re: Proposal: create XML based .gorm format: .xorm

--000000000000f50e1706572c835d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Guys,
As our team grows, the binary nature of .gorm files is becoming untenable.
Because Git cannot merge binary files, concurrent changes result in merge
conflicts where "the last person to merge wins."
While looking for alternatives, I evaluated standard Apple formats but
found significant limitations:

   - XML NIBs: These are referential rather than compositional. Objects are
   serialized into a flat list with positional indexes, making them just as
   difficult to merge as binary files.
   - XIBs: While compositional, Apple controls this format. It changes at
   their whim and is tightly coupled with their specific Cocoa nuances=E2=
=80=94nuances
   I have spent significant effort reverse-engineering.

While we can easily read these formats, writing to them will always be
imperfect. Therefore, I propose we design a custom, project-controlled
serialization format that meets three criteria:

   1. Compositional Structure: Nested objects should reflect the actual UI
   hierarchy (e.g., nesting an NSView inside an NSWindow tag).
   2. Human-Readable & Editable: This will allow clean version control and
   manual merging.
   3. Project-Controlled: We dictate the schema, protecting us from
   external breaking changes.

*Note: The underlying data format doesn't have to be XML; we can decide
between JSON, Plists, or XML later.*
Implementation Strategy:
To support this, we will need to implement custom versions of initWithCoder=
:
and encodeWithCoder:. I suggest extending the existing archiver methods to
include a check like allowsXormCoding (working title), similar to
allowsKeyedCoding.
I would love to hear your thoughts on this approach.
Yours, GC

On Tue, Jul 21, 2026 at 12:18=E2=80=AFPM R Frith-Macdonald <
[email protected]> wrote:

> Using -[NSDictionary descriptionWithLocale:indent:] I think we can
> already output a gorm file as a text property list with no indentation
> (and it sorts dictionary content by key).
>
> I suspect that format would be highly suitable for diff:
>
> Using no indent means that adding enclosing containers doesn't change
> the lines representing the content of those containers.
>
> Having dictionaries sorted by key means that fields are present in a
> consistent order.
>
> On 21/07/2026 16:41, Riccardo Mottola wrote:
> > David Wetzel via Discussion list for the GNUstep programming
> > environment wrote:
> >> I feel like XML is a format from the past. Why not use a JSON based on=
e?
> >
> > I would use neither, I would just use plists, our native format.
> > Actually, probably both plist as XML-encoded plists would work.
> >
> > JSON is just a bad plist :) and has absolutely no type encoding.
> >
> > Riccardo
> >
>
>

--=20
Gregory Casamento
GNUstep Lead Developer / Black Lotus, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
https://www.openhub.net/languages/objective_c

--000000000000f50e1706572c835d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D""><div class=3D"gmai=
l-n6owBd gmail-awi2gc" style=3D"margin:12px 0px 16px;border-bottom:0px rgb(=
230,232,240)"><font face=3D"monospace" style=3D"">Hey Guys,</font></div><di=
v class=3D"gmail-n6owBd gmail-awi2gc" style=3D"margin:12px 0px 16px;border-=
bottom:0px rgb(230,232,240)"><font face=3D"monospace">As our team grows, th=
e binary nature of <code dir=3D"ltr" class=3D"gmail-KDcb0c" style=3D"margin=
:0px;border-bottom:1px solid rgb(44,46,53)">.gorm</code> files is becoming =
untenable. Because Git cannot merge binary files, concurrent changes result=
 in merge conflicts where &quot;the last person to merge wins.&quot;</font>=
</div><div class=3D"gmail-n6owBd gmail-awi2gc" style=3D"margin:12px 0px 16p=
x;border-bottom:0px rgb(230,232,240)"><font face=3D"monospace">While lookin=
g for alternatives, I evaluated standard Apple formats but found significan=
t limitations:</font></div><ul class=3D"gmail-KsbFXc gmail-U6u95" style=3D"=
margin:12px 0px 16px;border-bottom:0px rgb(230,232,240)"><li class=3D"gmail=
-Z1qcYe" style=3D"margin:0px 0px 12px;border-bottom:0px rgb(230,232,240)"><=
span class=3D"gmail-iNqyIf" style=3D"margin:0px;border-bottom:0px rgb(230,2=
32,240)"><font face=3D"monospace"><span class=3D"gmail-Yjhzub" style=3D"fon=
t-weight:700;margin:0px;border-bottom:0px rgb(230,232,240)">XML NIBs:</span=
> These are referential rather than compositional. Objects are serialized i=
nto a flat list with positional indexes, making them just as difficult to m=
erge as binary files.</font></span></li><li class=3D"gmail-Z1qcYe" style=3D=
"margin:0px 0px 12px;border-bottom:0px rgb(230,232,240)"><span class=3D"gma=
il-iNqyIf" style=3D"margin:0px;border-bottom:0px rgb(230,232,240)"><font fa=
ce=3D"monospace"><span class=3D"gmail-Yjhzub" style=3D"font-weight:700;marg=
in:0px;border-bottom:0px rgb(230,232,240)">XIBs:</span> While compositional=
, Apple controls this format. It changes at their whim and is tightly coupl=
ed with their specific Cocoa nuances=E2=80=94nuances I have spent significa=
nt effort reverse-engineering.</font></span></li></ul><div class=3D"gmail-n=
6owBd gmail-awi2gc" style=3D"margin:12px 0px 16px;border-bottom:0px rgb(230=
,232,240)"><font face=3D"monospace">While we can easily read these formats,=
 writing to them will always be imperfect. Therefore, I propose we design a=
 custom, project-controlled serialization format that meets three criteria:=
</font></div><ol class=3D"gmail-IaGLZe gmail-VimKh" style=3D"margin:12px 0p=
x 16px;border-bottom:0px rgb(230,232,240)"><li class=3D"gmail-Z1qcYe" style=
=3D"margin:0px 0px 12px;border-bottom:0px rgb(230,232,240)"><span class=3D"=
gmail-iNqyIf" style=3D"margin:0px;border-bottom:0px rgb(230,232,240)"><font=
 face=3D"monospace"><span class=3D"gmail-Yjhzub" style=3D"font-weight:700;m=
argin:0px;border-bottom:0px rgb(230,232,240)">Compositional Structure:</spa=
n> Nested objects should reflect the actual UI hierarchy (e.g., nesting an =
<code dir=3D"ltr" class=3D"gmail-KDcb0c" style=3D"margin:0px;border-bottom:=
1px solid rgb(44,46,53)">NSView</code> inside an <code dir=3D"ltr" class=3D=
"gmail-KDcb0c" style=3D"margin:0px;border-bottom:1px solid rgb(44,46,53)">N=
SWindow</code> tag).</font></span></li><li class=3D"gmail-Z1qcYe" style=3D"=
margin:0px 0px 12px;border-bottom:0px rgb(230,232,240)"><span class=3D"gmai=
l-iNqyIf" style=3D"margin:0px;border-bottom:0px rgb(230,232,240)"><font fac=
e=3D"monospace"><span class=3D"gmail-Yjhzub" style=3D"font-weight:700;margi=
n:0px;border-bottom:0px rgb(230,232,240)">Human-Readable &amp; Editable:</s=
pan> This will allow clean version control and manual merging.</font></span=
></li><li class=3D"gmail-Z1qcYe" style=3D"margin:0px 0px 12px;border-bottom=
:0px rgb(230,232,240)"><span class=3D"gmail-iNqyIf" style=3D"margin:0px;bor=
der-bottom:0px rgb(230,232,240)"><font face=3D"monospace"><span class=3D"gm=
ail-Yjhzub" style=3D"font-weight:700;margin:0px;border-bottom:0px rgb(230,2=
32,240)">Project-Controlled:</span> We dictate the schema, protecting us fr=
om external breaking changes.</font></span></li></ol><div class=3D"gmail-n6=
owBd gmail-awi2gc" style=3D"margin:12px 0px 16px;border-bottom:0px rgb(230,=
232,240)"><em class=3D"eujQNb" style=3D"margin:0px;border-bottom:0px rgb(23=
0,232,240)"><font face=3D"monospace">Note: The underlying data format doesn=
&#39;t have to be XML; we can decide between JSON, Plists, or XML later.</f=
ont></em></div><div class=3D"gmail-n6owBd gmail-awi2gc" style=3D"margin:12p=
x 0px 16px;border-bottom:0px rgb(230,232,240)"><font face=3D"monospace"><sp=
an class=3D"gmail-Yjhzub" style=3D"font-weight:700;margin:0px;border-bottom=
:0px rgb(230,232,240)">Implementation Strategy:</span><br style=3D"margin:0=
px;border-bottom:0px rgb(230,232,240)">To support this, we will need to imp=
lement custom versions of <code dir=3D"ltr" class=3D"gmail-KDcb0c" style=3D=
"margin:0px;border-bottom:1px solid rgb(44,46,53)">initWithCoder:</code> an=
d <code dir=3D"ltr" class=3D"gmail-KDcb0c" style=3D"margin:0px;border-botto=
m:1px solid rgb(44,46,53)">encodeWithCoder:</code>. I suggest extending the=
 existing archiver methods to include a check like <code dir=3D"ltr" class=
=3D"gmail-KDcb0c" style=3D"margin:0px;border-bottom:1px solid rgb(44,46,53)=
"><span aria-invalid=3D"spelling" class=3D"LI ng" style=3D"border-style:non=
e;background:none">allowsXormCoding</span></code> (working title), similar =
to <code dir=3D"ltr" class=3D"gmail-KDcb0c" style=3D"margin:0px;border-bott=
om:1px solid rgb(44,46,53)">allowsKeyedCoding</code>.</font></div><div clas=
s=3D"gmail-n6owBd gmail-awi2gc" style=3D"margin:12px 0px 16px;border-bottom=
:0px rgb(230,232,240)"><font face=3D"monospace">I would love to hear your t=
houghts on this approach.</font></div><div class=3D"gmail-n6owBd gmail-awi2=
gc" style=3D"margin:12px 0px 16px;border-bottom:0px rgb(230,232,240)"><font=
 face=3D"monospace" style=3D""><span style=3D"background-color:transparent"=
>Yours,=C2=A0</span><span style=3D"background-color:transparent">GC</span><=
/font></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Tue, Jul 21, 2026 at 12:18=E2=80=AFPM R Frith-Macdonal=
d &lt;<a href=3D"mailto:[email protected]" target=3D"_blank">ric=
[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">Using -[NSDictionary descriptionWithLocale:indent:=
] I think we can <br>
already output a gorm file as a text property list with no indentation <br>
(and it sorts dictionary content by key).<br>
<br>
I suspect that format would be highly suitable for diff:<br>
<br>
Using no indent means that adding enclosing containers doesn&#39;t change <=
br>
the lines representing the content of those containers.<br>
<br>
Having dictionaries sorted by key means that fields are present in a <br>
consistent order.<br>
<br>
On 21/07/2026 16:41, Riccardo Mottola wrote:<br>
&gt; David Wetzel via Discussion list for the GNUstep programming <br>
&gt; environment wrote:<br>
&gt;&gt; I feel like XML is a format from the past. Why not use a JSON base=
d one?<br>
&gt;<br>
&gt; I would use neither, I would just use plists, our native format.<br>
&gt; Actually, probably both plist as XML-encoded plists would work.<br>
&gt;<br>
&gt; JSON is just a bad plist :) and has absolutely no type encoding.<br>
&gt;<br>
&gt; Riccardo<br>
&gt;<br>
<br>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr"><div dir=3D"ltr"><div><div dir=3D"ltr"><font fac=
e=3D"monospace">Gregory Casamento<br>GNUstep Lead Developer / Black Lotus, =
Principal Consultant<br><a href=3D"http://www.gnustep.org" target=3D"_blank=
">http://www.gnustep.org</a> - <a href=3D"http://heronsperch.blogspot.com" =
target=3D"_blank">http://heronsperch.blogspot.com</a><br></font></div></div=
><div dir=3D"ltr"><font color=3D"#888888" face=3D"monospace"><a href=3D"htt=
ps://www.openhub.net/languages/objective_c" style=3D"color:rgb(17,85,204)" =
target=3D"_blank">https://www.openhub.net/languages/objective_c</a></font><=
/div></div></div></div>

--000000000000f50e1706572c835d--