This is the clearest description of the milestone vs containers, BCV vs BSP issue I've seen so far. Thanks for the summary. It's very helpful.<span></span><div><br></div><div>~A<br><br>On Friday, September 21, 2012, DM Smith wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>So far the discussion is around whether the xml is well-formed.</div><div>Once you get that working, then you need to make sure it is valid wrt the OSIS schema.</div>
<div><br></div><div>There's an old tool that will convert sgml to well-formed xml. I think it was James Clark's "sx". I've used it successfully on initial conversions and getting something that will work within xml tools.</div>
<div><br></div><div>Finally, OSIS has the notion of milestones for start and end elements. There are semantic rules regarding this that cannot be checked by standard xml tools. Osis2mod tries to handle this. When you get to that point, I can help unravel the logging options.</div>
<div><br></div><div>The purpose of milestoned elements is to allow for two competing document models to be in the same xml document: BSP and BCV (names we've given it here and in the wiki).</div><div><br></div><div>We recommend using BSP (book, chapter, section, paragraph, poetry, lists to all be containers, not milestoned) and verse elements be milestoned.</div>
<div><br></div><div>Note, the OSIS manual says that if you have one element milestoned, then all other elements with the same tag name have to be milestoned. Practically speaking, this does not matter. SWORD and JSword don't care. Having verses milestoned only if necessary is probably a better way to create a good XML document. Start out with all of them as containers and each place where that causes a problem, either fix the xml or if otherwise correct, convert to milestoned verses.</div>
<div><br></div><div>Generally speaking these BSP elements should not start just inside or at the end of a verse. Rather they should be between verse elements or within the text. When they are placed just after the verse start, they often will cause the verse number to be orphaned. When they are placed just before the verse end, then it is generally not noticeable (just bad form).</div>
<div><br></div><div>Quotes will create the biggest grief in the above. They often cross boundaries. Certainly, the beatitudes does, starting in one chapter and ending a couple of chapters later. For this reason, using the milestoned version is necessary.</div>
<div><br></div><div>If you're document follows some simple rules (some required by xml, others simplifications), then checking nesting is a simple matter of having a push/pop stack of elements. The simple rules:</div>
<div>1) All attributes when present have quoted values.</div><div>2) All entities are properly formed and used when needed. Also, < and > are not in attribute values. </div><div>3) Tags are marked with < ... >, </ ... >, or < ... />. and now new lines between < and >.</div>
<div><br></div><div>If this is true then a simple perl script can be written to find the problems in the file:</div><div>Look for < ... /> and skip them. They cause no problems.</div><div>Look for < xxx ... > and push the tag name along with its location in the file on to the stack.</div>
<div>Look for < xxx />, compare xxx to the top element on the stack. If it doesn't match, then it causes an error.</div><div>When you get to the end of the document and the stack is not empty, then the elements on the stack are not closed properly.</div>
<div><br></div><div>Printing out the stack (elements and locations) would help find what the problem is.</div><div><br></div><div>For example:</div><div><span style="white-space:pre-wrap"> </span>if xxx is deeper in the stack, then there is a problem with nesting. Look at all the elements above the xxx on the stack for problems.</div>
<div><span style="white-space:pre-wrap"> </span>if it is not in the stack, then the element was not started prior to that point or it may have been ended twice.</div><div><br></div><div>Here is a simple perl script (that I wrote), which doesn't do that, but could be adapted to do it. This creates a histogram/dictionary of tag and attribute names.</div>
<div><br></div><div><div>#!/usr/bin/perl</div><div><br></div><div>use strict;</div><div><br></div><div>my %tags = ();</div><div>my %attrs = ();</div><div>while (<>)</div><div> {</div><div>#print;</div><div> # While there is a tag on the line</div>
<div> while (/<[^\/\s>]+[\/\s>]/o)</div><div> {</div><div> # While there is an attribute in the tag</div><div> while (/<[^\/\s>]+\s+[^\=\/\>]+=\"[^\"]+\"/o)</div><div><span style="white-space:pre-wrap"> </span>{</div>
<div><span style="white-space:pre-wrap"> </span> # remove the attribute</div><div><span style="white-space:pre-wrap"> </span> s/<([^\/\s>]+)\s+([^\=\/\>]+)(\="[^\"]+\")(.*)/<$1 $4/o;</div><div>
<span style="white-space:pre-wrap"> </span> my ($t, $a, $v, $r) = ($1, $2, $3, $4);</div><div><span style="white-space:pre-wrap"> </span> $attrs{"$t.$a"}++;</div><div><span style="white-space:pre-wrap"> </span>}</div>
<div> # remove the tag</div><div> s/<([^\/\s>]+)[\/\s>]//o;</div><div> $tags{$1}++;</div><div>#print("do next tag on line\n");</div><div> }</div><div>#print("do next line\n");</div>
<div> }</div><div><br></div><div>foreach my $tag (sort keys %tags)</div><div> {</div><div> print("$tag\n");</div><div> }</div><div><br></div><div>foreach my $attr (sort keys %attrs)</div><div> {</div><div>
print("$attr\n");</div><div> }</div></div><div><br></div><div>Hope this helps,</div><div><span style="white-space:pre-wrap"> </span>DM</div><br><div><div><div>On Sep 21, 2012, at 10:52 AM, Andrew Thule <<a href="javascript:_e({}, 'cvml', 'thulester@gmail.com');" target="_blank">thulester@gmail.com</a>> wrote:</div>
<br><blockquote type="cite">Thanks everyone for suggestions. I'll give them all a try. <div><br></div><div>That said, the emacs recommendation is nearly a religious conversion recommendation. (I'm on the vi side of the vi verses emacs debate. I suppose as long as it doesn't kill me I should give it a try, though I'm not certain what impact it will have on the health of my soul ... :D )</div>
<div><br></div><div>~A</div><div><br><br>On Thursday, September 20, 2012, Daniel Owens wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I use jEdit with the XML plugin installed. I find it helps me find problems fairly easily.<br>
<br>
Daniel<br>
<br>
On 09/20/2012 05:26 PM, Greg Hellings wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are a number of pieces of software out there that will<br>
pretty-print the XML for you, with indenting and whatnot. Overly<br>
indented for what you would want in production but decent for<br>
debugging mismatching nesting and the like.<br>
<br>
For example, 'xmllint --format' will properly indent the file, etc. I<br>
don't know how it will handle poorly formed XML.<br>
<br>
GUI editors can do wonders as well. On Windows I use Notepad++ and<br>
manually set it to display XML. gEdit and Geany - I believe - both<br>
support similar display worlds. And there are some plugins for Eclipse<br>
that might handle what you need as well.<br>
<br>
--Greg<br>
<br>
On Thu, Sep 20, 2012 at 4:19 PM, Karl Kleinpaste <<a>karl@kleinpaste.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Andrew Thule <<a>thulester@gmail.com</a>> writes:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One of my least favour things is finding mismatched tags in OSIS.xml files<br>
Has anyone successfully climbed this summit?<br>
</blockquote>
XEmacs and xml-mode (and font-lock-mode). M-C-f and M-C-b execute<br>
sgml-forward-element and -backward-. That is, sitting at the beginning<br>
of <tag>, M-C-f (meta-control-f) moves forward to the matching </tag>,<br>
properly handling nested tags.<br>
<br>
______________________________<u></u>_________________<br>
sword-devel mailing list: <a>sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/<u></u>mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote>
______________________________<u></u>_________________<br>
sword-devel mailing list: <a>sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/<u></u>mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
<br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
sword-devel mailing list: <a>sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/<u></u>mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote></div><span></span>
_______________________________________________<br>sword-devel mailing list: <a href="javascript:_e({}, 'cvml', 'sword-devel@crosswire.org');" target="_blank">sword-devel@crosswire.org</a><br><a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page</blockquote></div><br></div></div></blockquote></div>