Bug #454

hierarchy difference with FLEx

Added by Beth Bryson over 1 year ago. Updated 9 months ago.

Status:New Start:07/20/2010
Priority:Normal Due date:
Assigned to:- % Done:

0%
Category:application Spent time: -
Target version:V1.1.x
Resolution:

Description

I'm not totally sure what the issue here is, but there is a discrepancy between how SOLID is treating this and how FLEx is treating it. It would be helpful if SOLID could help me figure out what FLEx was going to do with this.

In SOLID, I said that \bw had to be under only \lx. (I deleted \se as a possible parent.) I have an entry like this:

\lx bayar
\se mambayar
\bw Ind
\ps n
....
\st rn
\dt 17/Jul/2009

I had hoped that SOLID could tell me that I incorrectly had a \bw inside my \se. Instead, it treated the \bw as a child of \lx and a sister of \se. And \ps was also a sister of both of these.

But when I imported into FLEx, the \bw showed up in the subentry (mambayar) not in the main entry (bayar).

However, the fields at the very bottom of the record, \st and \dt (that are designated as children of \lx), did end up in the main entry.

So, I don't totally understand what FLEx's algorithm is and how it is different from SOLID's. But it sure would be nice to have a way of detecting situations like this, FLEx is not going to do what I want, and I would like a chance ahead of time to rearrange things.

Sample-bw.db (323 Bytes) Beth Bryson, 07/20/2010 03:49 am

Sample-bw.solid (75.3 KB) Beth Bryson, 07/20/2010 03:49 am

BW.png (187.9 KB) Timothy Armstrong, 07/21/2010 01:26 am

History

#1
Updated by Beth Bryson over 1 year ago

Here is a tiny database with just this record in it, plus the SOLID settings I used.

#2
Updated by Timothy Armstrong over 1 year ago

Here is the corrected image that goes with the above post.

#3
Updated by Timothy Armstrong over 1 year ago

  • File deleted (BW.png)

#4
Updated by Cambell Prince over 1 year ago

  • Category set to application

Beth Bryson wrote:

lx bayar se mambayar bw Ind ps n .... st rn dt 17/Jul/2009

The thing is that looks perfectly ambiguous and legal both ways to me. Although if taking the ps under lx then that leaves the se being empty which is non-sensical. So if I add an (optional) rule that says "here's an empty parent" then that would detect it.

#5
Updated by Cambell Prince over 1 year ago

  • Target version set to V1.1.x

Here solid let's you state what the data means. Is bw lx only, or can it be under se. Flex is hardwired to allow bw under se also. The structure rules in Solid aren't going to let you see this. I could write a new error filter (bottom left pane) that would show entry level markers in the middle.

Somewhat more technically, show the markers that force an exit back up to a higher level of the hierarchy.

e.g. "Marker 'bw' terminated an 'sn'"

#6
Updated by J C 9 months ago

Yeah, as you all know, one of the inherent problems with SFM (as opposed to, say, XML) is that the lack of closing tags creates ambiguities.

E.g. I think that ordinarily it's ambiguous whether \bw is supposed to be a child of \se or of \lx. But since \se was disallowed as a parent in this case, \bw must be a child of \lx, and so must \ps in order to not generate an error. The example above would generate an error if there were more than one \se field there. (But there's only one \se here, so Solid doesn't see this as an error.)

Likewise, \st looks ambiguous to me. I believe that Solid interprets most fields as applying to the "deepest possible" level; i.e. to \se instead of \lx where possible (but not possible in this case because \bw terminated the \se). So, normally, if \st can be under either the entry- or subentry-level, but the user wants \st at the entry level, s/he would have to it it up above the first \se field.

Normally, the \dt field is fine at the end of the record because it isn't allowed as a child of \se. But if Cambell implements his new error filter ("show the markers that force an exit back up to a higher level of the hierarchy") then all \dt fields would show up as errors and need to be moved up, right? I can't think of a simple way around that. Sigh.

JC

#7
Updated by J C 9 months ago

Oh, I had forgotten about the proposed solution for issue 403, which has been very nicely implemented.

http://projects.palaso.org/issues/403 intervening markers vs preceding markers

So, it's probably ok to close this issue as well. Maybe Beth can verify whether this problem is now fully resolved or not.

#8
Updated by J C 9 months ago

Oops. Actually, looking more closely I don't think this issue was resolved by resolving #403. Hopefully issue #435 was, but I guess this one is trickier. Sorry if I suggested closing it prematurely.

Also available in: Atom PDF