Sean,
This may be complicated to address with simplicity (love that language), but I'll take a shot at it.
-------------------------------------------------------------------------------
Question A)
E:Head[H1],p+,(p|ul|ol|GRAPHIC|Table|Anchor|E:Section[S2])* in the element Section[S1].
That is, the included 1 or more E:Section[S2] might itself contain an E:Section[S3], but the Section[S1] would not have that outside of the Section[S2]. So, should I include E:Section[S3] in the Section[S1] definition?
RW: No. Each rule like this is specifying the direct child candidates only. You would have a separate row in your table for Section[S2}, which specifies its respective candidate children (one of which, Section[S3]. Likewise, Section[S3] would have its own row, etc.
----------------------------------------------------------------------------------
Question B)
Also, I don't see TEXT specified anywhere in the samples I am looking at. Should TEXT be in my conversion table?
Am I correct that I should add my lists to these right, if I want lists to be valid in Sections?
RW: No. By nature, a text node is locked to its current position, as a child of its current parent. Wherever that parent goes, the child text node must go too. So, no choice in the matter. Naturally, though, the general rule in your EDD must allow text as applicable to maintain validity.
As a further explanation, consider how a text node appears... normally by wrapping some text in a character range element, where there is additional text before and/or after within the paragraph. The conversion table normally does this wrapping based on character formats, then the text nodes are just there and fixed.
-------------------------------------------------------------------------------
Question C)
Also, I understand that the following specifices 0 or more of the contained elements: E:Head[H1],p+,(p|ul|ol|GRAPHIC|Table|Anchor|E:Section[S2])* in the element Section[S1].
However, the reality is for E:Secton[S2] there has to be two or more, or none (there cannot be just one). So, does the following describe what I just said?
E:Head[H1],p+,(p|ul|ol|GRAPHIC|Table|Anchor|(E:Section[S2],E:Section[S2]+))*
RW: The logic looks incorrect to me. I don't know exactly what your EDD or source file looks like, but I would think more along the lines of something like:
E:Head[H1],p+,(p|ul|ol|GRAPHIC|Table|Anchor)*,Section[S2],Section[S2]+
Otherwise, you could get more <p>, <ul>, etc. after the sections. While we are on this question, let me throw out a few more thoughts...
- You have to decide whether you are trying to strictly enforce structural rules here or simply get the best-possible structure applied. Typically, a conversion table rule might be more lenient so it can capture anomalies that can be later cleared up by using EDD validation. With additional consideration of another convention you have implied, that a section must start with a <p>, I would typically use a simpler rule, like:
E:Head[H1],(p|ul|ol|GRAPHIC|Table|Anchor)*,Section[S2]*
Maybe this is more lenient than the structure you intend to enforce in your documents. But it is much more likely to get your initial structure more workable from the start. During post-conversion cleanup, it is much easier to fix a few misplaced <p> elements than to rearrange a bunch of section hierarchies, just because you sought perfection in the first pass.
- Again, although not knowing your EDD, this jumps out at me... by putting GRAPHIC, Table, and Anchor in a single rule, this implies that they must be siblings. However, based on previous conversations, I'm suspicious that they are not. That is, I suspect that Anchor may be a parent to the other two. If so, this rule should have Anchor only, and there should be separate rules to shove the GRAPHIC and Table elements under Anchor, so then that this rule simply needs to pull in the Anchor and any children.
-------------------------------------------------------------------------------
Hope this helps!
Russ
1 Correct answer
1
Reply
AdChoices