Question: The use of CONT v5.5.1 vs v7.0

[Norwegian-Sardines]

I’ve been reading GEDCOM for more than 40years both the good and bad of it!

in v5.5.1 I always could see and read the places where the CONT/CONC was used in structures, but in v7 the inclusion of the CONT/CONC has been remove. I realize that the CONC is no longer needed as the line length issues (computer cards) is no longer a thing.

However, I’m never clear when/where a CONT is still valid! For example:

In v5.5.1 the address_structure indicated a CONT was permissible 3 times, but in v7 the structure layout does not indicate this! The text below the structure references the use of CONT but the words don’t tell me what the v5.5.1 tells me!

Another case is the PUBL tag of the Source_Record. In v5.5.1 we could see without a doubt that the PUBL was a multi line structure, in v7 this is not the case. Am I to assume that the publication information is now one long line. This would be detrimental to the use of this tag when creating a citation from GEDCOM. Normally I would enter all of the publishers information in a similar form as the Address_Structure and when I need to build a citation only take the first line, the publishers name!

I’m sure other structure have the same design but today I am thinking about citations and bibliography data!

Please help me to understand!

[dthaler]

Section 1.3 says:

Each non-pointer payload may be encoded in 1 or more line strings (line continuations encode multi-line payloads in several line strings).

So a PUBL (having a non-pointer payload) can certainly have multiple lines.

Line continuation pseudo-structures are not considered to be structures. While they match production Line and their level and position makes them appear to be substructures of the structure, they are actually a continuation of the encoding of the structure’s payload and are not part of a structure’s collection of substructures.

So CONT doesn't appear in the gedstruct definitions because it's a pseudo-structure valid everywhere non-pointer payloads are allowed.

Previous versions limited the number of characters that could appear in a tag, cross-reference identifier, and line-value. Those restrictions were removed in version 7.0.

So there's no limit on how many CONT lines can appear, as long as the resulting payload is valid for the structure they apply to.

[Norwegian-Sardines]

Wow, I glad you translated that word salad to something my simple mind can understand!

So does that mean that since "DATE" is not a pointer that it can have multiple lines? The same would hold for PLAC as well and probably a lot of other tags?

[dthaler]

Wow, I glad you translated that word salad to something my simple mind can understand!

So does that mean that since "DATE" is not a pointer that it can have multiple lines? The same would hold for PLAC as well and probably a lot of other tags?

Only structures whose payload is permitted to include a newline can have multiple lines. For example, any structure whose type is <Text> can. My reading is that yes PLAC (whose payload is <List:Text>) can, but DATE cannot, since newline is not a valid character in <DateValue>.

[Norwegian-Sardines]

And ADDR is defined as <Special> so this type can also have multiple lines!

[Norwegian-Sardines]

My guess at this point is that the payload will not contain a CONT tag anymore. And programs that read the incoming payload will now have to parse on “new line” vs CONT.

[dthaler]

The grammar in section 1.3 doesn't allow a newline in a LineVal, so the only way to include a newline in a payload is to use a CONT tag.

[tychonievich]

Another take on this:

The 5.5.1 spec had definitions of CONT and CONC that was not consistent with practice or intent. As written, you could swap the order of a CONC and CONT (which was self-evidently incorrect, allowing text to be scrambled) and interleave them with substructures (which most applications we tested did not support). The 7.0.0 drafting team wanted the spec to be complete without these kinds of differences between spec and practice, so we needed to re-define how CONT was defined.

In doing this, we also noted other things that made CONT special. It should always come before any substructure. It should never have substructures of its own, not even extension substructures. It was sometimes omitted from the spec in places where it made sense (e.g. HEAD.SOUR.DATA.COPR had it but HEAD.COPR did not, but both have copyrights as their payload). The 5.5.1 spec often described what a line value meant, but in a way that only made sense if you applied it to the line value and the line values of any subsequent CONT and CONC.

We thus introduced a new term, "payload," in the 7.0 spec to refer to the line value concatenated with all CONT line values. We defined structure meanings referring to the payloads, not the line values. And we defined how to convert between a payload that has line breaks and a sequence of lines. The intent is that this accurately describes how all versions of GEDCOM have used CONC and CONT, even though it it not how any previous version has specified them.

[Norwegian-Sardines]

So then the “payload” will contain a “n CONT” even though it is not specified in the GEDCOM Specification! If a new software program came along and read the specification how would they know that they needed to break on a “n CONT” to a new line without actually seeing that this meant something?

I get that CONT/CONC can’t have extension tags between and some new program might think they could do it, so you need to introduce the term payload. But I don’t see in the specification where someone knows that the “CONT” is included in the text line!

[dthaler]

"n CONT" is not part of the line value and so the payload does not contain an "n CONT".

Section 1.3 explains:

A line is a string representation of (part of) a structure. A line consists of a level, optional cross-reference identifier, tag, optional line value, and line terminator. It matches the production Line:

Line    = Level D [Xref D] Tag [D LineVal] EOL

...

The line value matches production LineVal and encodes the structure’s payload.