May 2017 - Tei-council - lists.tei-c.org

paper submission for review
by Syd Bauman 15 May '17

15 May '17

Dear Council, Here is a 1st crack at my submission for the TEI conference, due tomorrow. I've listed all fields, but am only asking y'all to review and edit the abstract (which has to be <= 300 words -- it currently has 329), and to suggest a better title if one jumps to mind. ################################## Title ----- tei_customization: A TEI customization for writing TEI customizations Abstract -------- The TEI ODD language (and the more modern version thereof, Pure ODD) can be used for two related, but distinctly different purposes: 1) to *create* a markup language, including documentation and schemas; and 2) to *customize* a markup language that was already written in ODD. There are several examples of (1), including the TEI Guidelines, the Music Encoding Initiative, the ISO Feature Structure encoding system, the W3C Internationalization Tag Set, and a version of the Itsy Bitsy Teeny Weeny Simple Hypertext DTD. And there are several well known examples of (2), including TEI Lite, TEI Tite, TEI Simple Print, CBML, DALF, DHQ, jTEI, and the TEI in Libraries Best Practice Guidelines. But the TEI Guidelines are not meant to be used out of the box -- *every* TEI project is expected to customize the TEI, thus they are all expected to create a customization in ODD. The 'tei_odds' customization provided by the TEI is, understandably, a schema intended to check conformance with the rules for using ODD. Because ODD is used for two different things, and for both TEI and non-TEI languages, those rules are necessarily much more broad than those for writing TEI customizations. E.g., the value of the @key attribute of <moduleRef> can be any XML name. But when used to write a TEI customization, the only valid values are the actual names of TEI modules (e.g., "core", "textstructure", "header", "namesdates"). The tei_customization customization is not intended to produce a schema that can tell you what is "correct" or "incorrect", but rather to *help* you write a TEI customization. So, e.g., only the names of TEI modules are allowed as values of moduleRef/@key, and thus your editor can give you a pop-up box of those values. This paper will describe (and the talk will demonstrate use of) tei_customization, and discuss the interesting twist that this is not a schema whose rules must be obeyed, but rather an editing assistant. Keywords -------- TEI, Customization, ODD Bibliography ------------ 2016-08: “The Hard Edges of Soft Hyphens.” Presented at Balisage: The Markup Conference 2016, Washington, DC, August 2–5, 2016. In Proceedings of Balisage: The Markup Conference 2016. Balisage Series on Markup Technologies, vol. 17 (2016). DOI: 10.4242/BalisageVol17.Bauman01. 2013-10: “TAPAS and the TEI: An Update and Open Discussion” with Julia Flanders and Elena Pierazzo. Presented at The Linked TEI: Text Encoding in the Web: the TEI Conference, 2013, Rome, Italy, October 2–5, 2013 2013-06: “Encoding Historical Financial Records” with Kathryn Tomasek. Presented at Digital Humanities 2013, Lincoln, NE, July 17, 2013. 2012-11: “Encoding Financial Records for Historical Research” with Kathryn Tomasek. Presented at TEI and the C{rl}O{wu}D: the Text Encoding Initiative Conference, 2012, College Station, TX, November 8–10, 2012. In _Journal of the Text Encoding Initiative_, Issue 6 | December 2013. URL: http://jtei.revues.org/895; DOI: 10.4000/jtei.895 2011-08: “Interchange vs. Interoperability.” Presented at Balisage: The Markup Conference 2011, Montréal, Canada, August 2–5, 2011. In Proceedings of Balisage: The Markup Conference 2011. Balisage Series on Markup Technologies, vol. 7 (2011). doi:10.4242/BalisageVol7.Bauman01. Remark / Message to the Program Committee and Chairs ------ - ------- -- --- ------- --------- --- ------ Although I am indeed affiliated with Northeastern University (and that institution must be listed), I am also affiliated with the TEI Council, who charged me with writing this paper.

4 3

Build failed in Jenkins: Stylesheets-dev #2224
by Victoria TEI Jenkins 15 May '17

15 May '17

See <http://teijenkins.hcmc.uvic.ca/job/Stylesheets-dev/2224/display/redirect?pa…> Changes: [martina.scholger] change address to span [martina.scholger] span.address selector with default properties of html:address added ------------------------------------------ Started by an SCM change Building in workspace <http://teijenkins.hcmc.uvic.ca/job/Stylesheets-dev/ws/> > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url https://github.com/TEIC/Stylesheets.git # timeout=10 Fetching upstream changes from https://github.com/TEIC/Stylesheets.git > git --version # timeout=10 > git fetch --tags --progress https://github.com/TEIC/Stylesheets.git +refs/heads/*:refs/remotes/origin/* > git rev-parse refs/remotes/origin/dev^{commit} # timeout=10 > git rev-parse refs/remotes/origin/origin/dev^{commit} # timeout=10 Checking out Revision f43039a0dd7c52d4556f0c21fd7ad45e4f058cfd (refs/remotes/origin/dev) > git config core.sparsecheckout # timeout=10 > git checkout -f f43039a0dd7c52d4556f0c21fd7ad45e4f058cfd > git rev-list 2732cff12b94e3253ebb89b028dba98df58fcd2f # timeout=10 > git tag -a -f -m Jenkins Build #2224 jenkins-Stylesheets-dev-2224 # timeout=10 [workspace] $ /bin/bash -xe /tmp/jenkins4169995815636687477.sh + make clean test deb dist (for i in css/*; do rm -f `basename $i`;done) echo "" > test~ rm -f profile1.html profile2.html profile.xml find . -name "*~" | xargs rm rm -f tei-xsl-*.zip rm -rf tei-xsl_* rm -f Documentation/stylebear Documentation/style.xml Documentation/customize.xml Documentation/teixsl.html Documentation/index.xml rm -rf release dist (cd Test; make clean) make[1]: Entering directory `<http://teijenkins.hcmc.uvic.ca/job/Stylesheets-dev/ws/Test'> (cd ..; for i in css/*; do rm -f `basename $i`;done) rm -f test*.odd.rnc test*epub test*pdf test*rdf test*text test*.xml.docx test*.xml.odt test*.tex test*.fo *.html *.xhtml *~ dummy* test.html test3.html test4.html *aux *vrb *out *log *nav *ent *snm *toc *.end *.1 *.2 test.xsd test.zip test*.dtd test-indexes.xml test37.xml test38.xml test39.xml test40.xml rm -f test*.rnc test*.json test*.rnc test*.combined.odd test*listing* test*.tei test*.rng test*.html5 test*.processedodd *.isosch rm -f oddbyexample.* index*div*html rm -f testdrama.compiled.xml rm -f test5.odt test7.xml test18.xml test19.xml test-index.xml test7.zip test11.xml test9.docx test9.odt content.xml.odt.listing content.xml.odt test.xml.docx.core test7.docx rm -f A54031.xml dcr.result test-rtf2tei.xml test29.xml dcr.tmp xml.tmp rm -f xml.result rm -rf charts/ embeddings/ media/ _rels/ \[Content_Types\].xml rm -rf temp-dir-for-ant Pictures OEBPS META-INF mimetype files rm -f test.xlsx.xml *.result.tex *.result.pdf _slidelogo.png rm -f content.xml rm -f cocoatest*.xml make[1]: Leaving directory `<http://teijenkins.hcmc.uvic.ca/job/Stylesheets-dev/ws/Test'> rm -rf tei-p5-xsl_* rm -rf tei-p5-xsl2_* (cd debian-tei-xsl/debian; rm -rf tei-xsl) rm -f teioo.jar rm -rf docx/ImageInfo/bin rm -f names.xml licensekey.txt runDoc.sh (for i in sciencejournal/*.html; do rm -f sciencejournal/`basename $i`;done) (for i in sciencejournal/*.xml; do rm -f sciencejournal/`basename $i`;done) BUILD Copy main XSL files test -d release/xsl/xml/tei/stylesheet || mkdir -p release/xsl/xml/tei/stylesheet/ for i in bibtex cocoa common csv docx dtd docbook epub epub3 fo html wordpress markdown html5 json latex latex nlm odd odds odt p4 pdf profiles/default rdf relaxng rnc schematron simple slides tbx tcp tite tools txt html xsd xlsx pdf verbatimxml ; do \ tar cf - $i | (cd release/xsl/xml/tei/stylesheet; tar xf - ); \ done java -jar lib/saxon9he.jar -it:main tools/getnames.xsl > names.xml BUILD Copy common files and documentation test -d release/xslcommon/xml/tei/stylesheet || mkdir -p release/xslcommon/xml/tei/stylesheet cp names.xml catalog.xml VERSION css/*.css i18n.xml release/xslcommon/xml/tei/stylesheet sh ./tools/mydch debian-tei-xsl/debian/changelog update debian changelog with 7.43.0a BUILD Run tests (cd Test; make) make[1]: Entering directory `<http://teijenkins.hcmc.uvic.ca/job/Stylesheets-dev/ws/Test'> ../bin/teitorelaxng --odd test.odd test.rng WARNING: No localsource set. Will get a copy from http://www.tei-c.org/Vault/P5/. Convert test.odd to <http://teijenkins.hcmc.uvic.ca/job/Stylesheets-dev/ws/Test/test.rng> (tei to relaxng) using profile default [echo] Do ODD expand processing (schema ) Warning: XML resolver not found; external catalogs will be ignored BUILD SUCCESSFUL Total time: 18 seconds perl -i -p -e 's/generated from ODD source.*//' test.rng xmllint --format test.rng > temp; mv temp test.rng perl -i -pe 'BEGIN{undef $/;} s/<!--\n ?Schema[^>]+>//smg' test.rng if [ 0 -ne 1 ]; \ then diff test.rng expected-results/test.rng; fi (cd ..; for i in css/*; do test -f `basename $i` || ln -s $i `basename $i`;done) BUILD: testing html java -Djava.awt.headless=true -jar ../lib/saxon9he.jar test.xml ../html/html.xsl cssFile=../tei.css useFixedDate=true | xmllint --format - > test.html if [ 0 -ne 1 ]; \ then diff test.html expected-results/test.html; fi java -Djava.awt.headless=true -jar ../lib/saxon9he.jar test.html checklinks.xsl java -Djava.awt.headless=true -jar ../lib/saxon9he.jar test.xml ../html/html.xsl cssFile=../tei.css pageLayout=Complex useFixedDate=true | xmllint --format - > test-complex.html if [ 0 -ne 1 ]; \ then diff test-complex.html expected-results/test-complex.html; fi java -Djava.awt.headless=true -jar ../lib/saxon9he.jar test.xml ../profiles/ota/html/to.xsl cssFile=../tei.css useFixedDate=true | xmllint --format - | perl cleanup.pl > test-ota.html if [ 0 -ne 1 ]; \ then diff test-ota.html expected-results/test-ota.html; fi ../bin/teitohtml5 test.xml test.html5 WARNING: No localsource set. Will get a copy from http://www.tei-c.org/Vault/P5/. Convert test.xml to <http://teijenkins.hcmc.uvic.ca/job/Stylesheets-dev/ws/Test/test.html5> (tei to html5) using profile default [echo] XSLT generate HTML files (language en) Warning: XML resolver not found; external catalogs will be ignored BUILD SUCCESSFUL Total time: 5 seconds xmllint --encode utf-8 --format test.html5 | perl cleanup.pl > test.temp mv test.temp test.html5 if [ 0 -ne 1 ]; \ then diff test.html5 expected-results/test.html5; fi java -Djava.awt.headless=true -jar ../lib/saxon9he.jar test20.xml ../html/html.xsl useFixedDate=true | xmllint --format - > test20.html if [ 0 -ne 1 ]; \ then diff test20.html expected-results/test20.html; fi java -Djava.awt.headless=true -jar ../lib/saxon9he.jar -versionmsg:off test3.xml ../html/html.xsl useFixedDate=true| xmllint --format - > test3.html java -Djava.awt.headless=true -jar ../lib/saxon9he.jar -versionmsg:off test4.xml ../html/html.xsl useFixedDate=true| xmllint --format - > test4.html if [ 0 -ne 1 ]; \ then diff test4.html test3.html; fi java -Djava.awt.headless=true -jar ../lib/saxon9he.jar test5.xml ../html/html.xsl autoBlockQuote=true useFixedDate=true | xmllint --format - > test5.xhtml if [ 0 -ne 1 ]; \ then diff test5.xhtml expected-results/test5.xhtml; fi java -Djava.awt.headless=true -jar ../lib/lib/jing-20120724.0.0.jar -c xhtml.rnc test5.xhtml java -Djava.awt.headless=true -jar ../lib/saxon9he.jar test6.xml ../html/html.xsl autoBlockQuote=true useFixedDate=true | xmllint --format - > test6.html if [ 0 -ne 1 ]; \ then diff test6.html expected-results/test6.html; fi java -Djava.awt.headless=true -jar ../lib/lib/jing-20120724.0.0.jar -c xhtml.rnc test6.html java -Djava.awt.headless=true -jar ../lib/saxon9he.jar test14.xml ../html/html.xsl useFixedDate=true| xmllint --format - > test14.html if [ 0 -ne 1 ]; \ then diff test14.html expected-results/test14.html; fi java -Djava.awt.headless=true -jar ../lib/saxon9he.jar test22.xml ../html/html.xsl useFixedDate=true| xmllint --format - > test22.html if [ 0 -ne 1 ]; \ then diff test22.html expected-results/test22.html; fi java -Djava.awt.headless=true -jar ../lib/saxon9he.jar test23.xml ../html/html.xsl useFixedDate=true| xmllint --format - > test23.html if [ 0 -ne 1 ]; \ then diff test23.html expected-results/test23.html; fi 38c38 < via Marsala 2440126BolognaItaly --- > <address class="address">via Marsala 2440126BolognaItaly</address> 64c64 < --- > <address class="address"> 69c69 < --- > </address> 79c79 < via Marsala 2440126BolognaItaly --- > <address class="address">via Marsala 2440126BolognaItaly</address> make[1]: *** [test-to-html] Error 1 make[1]: Leaving directory `<http://teijenkins.hcmc.uvic.ca/job/Stylesheets-dev/ws/Test'> make: *** [test] Error 2 Build step 'Execute shell' marked build as failure Archiving artifacts

1 1

Fwd: deprecation information incomplete
by Kevin Hawkins 11 May '17

11 May '17

Council, The TEI webmasters received the below message from Lou. It took me a bit to figure out what he was referring to, but I've got it now. At http://www.tei-c.org/Activities/Council/Working/tcw27.xml , he suggests changing the first bullet under "Deprecated" from: * The appropriate spec is modified to add@validUntilon the appropriate<elementSpec>,<classRef>, or<attDef>elements. The value of@validUntilshall be no sooner than two years from the date of the change (thus guaranteeing/at least/one year from the release in which the deprecation is announced to the change in which the feature disappears). to: * The appropriate specification is given a@validUntilattribute indicating the intended date after which the specification will be withdrawn. Specifications which can be deprecated in this way are all members of the class att.deprecated. This seems straightforward, but please Luis and me know by April 1 if you object by replying to all. Kevin -------- Forwarded Message -------- Subject: deprecation information incomplete Date: Fri, 24 Mar 2017 21:24:40 +0000 From: Lou Burnard <lou.burnard(a)retired.ox.ac.uk> To: web(a)tei-c.org The list of elements which can carry a @validUntil attribute on this page is incomplete. The full list should be attDef <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-attDef.html> classSpec <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-classSpec.html> constraintSpec <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-constraintSpec.html> dataSpec <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-dataSpec.html> elementSpec <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-elementSpec.html> macroSpec <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-macroSpec.html> moduleSpec <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-moduleSpec.html> paramSpec <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-paramSpec.html> schemaSpec <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-schemaSpec.html> valDesc <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-valDesc.html> valItem <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-valItem.html> valList <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-valList.html> defaultVal. Or you could simply refer to the class att.deprecated. <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-defaultVal.html> "The appropriate spec is modified to add @validUntil on the appropriate <elementSpec> , <classRef> , or <attDef> elements." should perhaps change to say "The appropriate specification is given a @validUntil attribute indicating the intended date after which the the specification will be withdrawn. Specifications which can be deprecated in this way are all members of the class att.deprecated. "

1 1

@versionDate on <exemplum> in specs
by Sarah S 11 May '17

11 May '17

Hi all, As I was working on ticket #1623, I noticed @versionDate was being used inconsistently on <exemplum>. I found this this thread on translating the guidelines that discusses the topic: http://lists.lists.tei-c.org/pipermail/tei-council/2014/018902.html, but a consensus wasn't reached within that conversation. I was wondering if we ever officially decided on a policy? I added it to the exempla that I edited, because I figure it would be easier to go back and remove them than to add them. For reference, there appear to be 553 instances of <exemplum> with @versionDate in the Specs and nearly 1300 without it. Thanks! -Sarah Sarah Stanley Office of Digital Research and Scholarship Strozier Library, Florida State University https://www.lib.fsu.edu/drs/ Twitter: https://twitter.com/sarcathtic

1 0

Re: [tei-council] weird validation problem
by Elisa Beshero-Bondar 07 May '17

07 May '17

Dear Council-- The weird validation problem is solved: I needed to purge my system of DS_Store files (and this time I set up a proper "cron job" to keep removing them every day). My project's schema needs to check files within a collection, and the presence of a pesky DS_Store file was interfering (sigh). I feel pretty silly, but since errors generated by such things tend to be pretty dramatic, maybe it's worth filing away in future. Elisa On Sat, May 6, 2017 at 2:00 AM, Elisa Beshero-Bondar <ebb8(a)pitt.edu> wrote: > Dear Council-- > I'm seeing a weird schema validation problem since our Stylesheets meeting > on Thursday, just on my Mac OS X installation of oXygen version 19 (current > one). It's weird because I can't duplicate the problem on my (also current) > Linux installation of oXygen. I see it on my Mac only when I try to > validate the TEI files in one project, with an ODD-generated schema. On the > Mac, validation is interrupted with an error that seems to indicate a > problem with the .rng file: Here is the error message: > > Engine name: ISO Schematron > Severity: fatal > Description: Required item type of result of call to collection is node(); > supplied value has item type xs:base64Binary > Start location: 2620:10 > > Clicking on the error message opens my RNG schema file to line 2620, which > is simply: > <define name="model.choicePart"> > <choice> > <ref name="sic"/> > <ref name="corr"/> > <ref name="reg"/> > <ref name="orig"/> > <ref name="unclear"/> > <ref name="abbr"/> > <ref name="expan"/> > <ref name="supplied"/> > <ref name="seg"/> > </choice> > </define> > This is a standard TEI schema rule, and I see no reason why it would be > failing. > > On my Linux computer, I've checked to see that it is running the same > version of oXygen as my Mac, and validation of the same files is performing > with no problems there. So something is wrong on my Mac, but I can't figure > out what. > > The only possibly event I can think of is that I installed Apache Ant on > my Mac using homebrew in my terminal two days ago during our Stylesheets > session, so that I could get the Stylesheets to properly run in their > sequence from our bin directory. But I don't know why that would interfere > with oXygen! > > Has anyone seen something similar or can advise? I've also written to > oXygen support. > > Thanks--and sorry to bug our group with this, but I wonder if it's an > ODD-related thing that we're likely to see more here than elsewhere... > > Elisa > > -- > Elisa Beshero-Bondar, PhD > Director, Center for the Digital Text | Associate Professor of English > University of Pittsburgh at Greensburg | Humanities Division > 150 Finoli Drive > Greensburg, PA 15601 USA > E-mail: ebb8(a)pitt.edu <ebb8(a)pitt.edu> > Development site: http://newtfire.org > -- Elisa Beshero-Bondar, PhD Director, Center for the Digital Text | Associate Professor of English University of Pittsburgh at Greensburg | Humanities Division 150 Finoli Drive Greensburg, PA 15601 USA E-mail: ebb8(a)pitt.edu <ebb8(a)pitt.edu> Development site: http://newtfire.org

1 0

weird validation problem
by Elisa Beshero-Bondar 06 May '17

06 May '17

Dear Council-- I'm seeing a weird schema validation problem since our Stylesheets meeting on Thursday, just on my Mac OS X installation of oXygen version 19 (current one). It's weird because I can't duplicate the problem on my (also current) Linux installation of oXygen. I see it on my Mac only when I try to validate the TEI files in one project, with an ODD-generated schema. On the Mac, validation is interrupted with an error that seems to indicate a problem with the .rng file: Here is the error message: Engine name: ISO Schematron Severity: fatal Description: Required item type of result of call to collection is node(); supplied value has item type xs:base64Binary Start location: 2620:10 Clicking on the error message opens my RNG schema file to line 2620, which is simply: <define name="model.choicePart"> <choice> <ref name="sic"/> <ref name="corr"/> <ref name="reg"/> <ref name="orig"/> <ref name="unclear"/> <ref name="abbr"/> <ref name="expan"/> <ref name="supplied"/> <ref name="seg"/> </choice> </define> This is a standard TEI schema rule, and I see no reason why it would be failing. On my Linux computer, I've checked to see that it is running the same version of oXygen as my Mac, and validation of the same files is performing with no problems there. So something is wrong on my Mac, but I can't figure out what. The only possibly event I can think of is that I installed Apache Ant on my Mac using homebrew in my terminal two days ago during our Stylesheets session, so that I could get the Stylesheets to properly run in their sequence from our bin directory. But I don't know why that would interfere with oXygen! Has anyone seen something similar or can advise? I've also written to oXygen support. Thanks--and sorry to bug our group with this, but I wonder if it's an ODD-related thing that we're likely to see more here than elsewhere... Elisa -- Elisa Beshero-Bondar, PhD Director, Center for the Digital Text | Associate Professor of English University of Pittsburgh at Greensburg | Humanities Division 150 Finoli Drive Greensburg, PA 15601 USA E-mail: ebb8(a)pitt.edu <ebb8(a)pitt.edu> Development site: http://newtfire.org

1 0

Re: [tei-council] co-operative stylesheet education session #9
by Alejandro Bia 04 May '17

04 May '17

How can I connect to the Google hangout? At 14:46 04/05/2017, Elisa Beshero-Bondar wrote: >Hi everyone-- >I became very stuck on this homework--in actually attempting to get a fix >to *process*--and I'm really stumped. I think I'm learning something about >the interdependency of the Stylesheets, but I'm really baffled, ready to >explain what I've tried, and I am hoping for enlightenment. I'm especially >stumped because I attempted what *looks* from Raff's "gist" to be the same >kind of fix he made, and it absolutely didn't work to alter my output. I >can see at least two ways, though, that we're processing to output an HTML >address element in two different contexts. > >Anyway, in case it's my sample file, I wanted to share it with the group. >This is a simplified version of a letter from my Digital Mitford project, >and the TEI address element is toward the end of the document: >https://github.com/ebeshero/Stylesheets/tree/dev/test_ebb The XML file is >my input, and the HTML is a stupid tester output that doesn't change >anything from the current way the Stylesheets are outputting. During the >session I'll share what I tried to change, and hope for enlightenment. > >Thanks, and looking forward to our session! >Elisa > > > >On Wed, Apr 26, 2017 at 12:20 PM, Syd Bauman <s.bauman(a)northeastern.edu> >wrote: > > > 1. Andrew, Marcus, Jure, and Ron -- would you like to continue to receive > > these e-mails? If so, speak up. > > > > 2. We're scheduled to meet on Thu 04 May at 13:00Z on Google > > Hangouts. > > > > 3. Per our previous e-mail discussion, we have HOME WORK to complete > > before this meeting. Our goal is to address ticket #261.[1] > > > > a) Read the ticket.[1] > > > > b) Make a small test TEI file that uses the <tei:address> element; if > > you can do so easily, put it up somewhere to share with the rest > > of us for step #4, below. > > > > c) Make a fork of the Stylesheets repo. > > > > d) Find the 2 files that generate <html:address>, and fix the one > > that is general-purpose, leaving the the one that is used in > > the footer for later -- extra credit :-) > > > > e) Decide what the HTML output (for <tei:address> input) should > > be, and implement a fix. > > > > f) Test and update your fix until it works.[2] > > > > g) Validate the HTML produced.[3] > > > > h) Find any CSS files that may need to be changed accordingly, > > and change 'em as needed. > > > > i) Share your test file and solution. > > > > 4. On the call we will try to run each solution on someone else's > > test file(s). > > > > Notes > > ----- > > [1] https://github.com/TEIC/Stylesheets/issues/261 > > [2] E.g., by running /path/to/Stylesheets/bin/teitohtml TEST.xml > > [3] E.g., by opening in oXygen or by uploading to either > > https://validator.nu/ or http://validator.w3.org/. > > -- > > tei-council mailing list > > tei-council(a)lists.tei-c.org > > http://lists.lists.tei-c.org/mailman/listinfo/tei-council > > > > PLEASE NOTE: postings to this list are publicly archived > > > > > >-- >Elisa Beshero-Bondar, PhD >Director, Center for the Digital Text | Associate Professor of English >University of Pittsburgh at Greensburg | Humanities Division >150 Finoli Drive >Greensburg, PA 15601 USA >E-mail: ebb8(a)pitt.edu <ebb8(a)pitt.edu> >Development site: http://newtfire.org >-- >tei-council mailing list >tei-council(a)lists.tei-c.org >http://lists.lists.tei-c.org/mailman/listinfo/tei-council > >PLEASE NOTE: postings to this list are publicly archived --------------------------------------------------------- ALEJANDRO BIA e-mail: abia(a)umh.es CIO - DEMI Centro de Investigación Operativa Departamento de Estadística, Matemáticas e Informática Área de Lenguajes y Sistemas Informáticos Universidad Miguel Hernández Ed. Torretamarit, Av. Universidad s/n, CP:03202, Elche, ESPAÑA Web: http://dhw.umh.es/alex-bia/ Tel: +34 966658973 Móvil: +34 644447008 Skype: alex-bia Twitter: @alex_bia --------------------------------------------------------- --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

4 4

co-operative stylesheet education session #9
by Syd Bauman 04 May '17

04 May '17

1. Andrew, Marcus, Jure, and Ron -- would you like to continue to receive these e-mails? If so, speak up. 2. We're scheduled to meet on Thu 04 May at 13:00Z on Google Hangouts. 3. Per our previous e-mail discussion, we have HOME WORK to complete before this meeting. Our goal is to address ticket #261.[1] a) Read the ticket.[1] b) Make a small test TEI file that uses the <tei:address> element; if you can do so easily, put it up somewhere to share with the rest of us for step #4, below. c) Make a fork of the Stylesheets repo. d) Find the 2 files that generate <html:address>, and fix the one that is general-purpose, leaving the the one that is used in the footer for later -- extra credit :-) e) Decide what the HTML output (for <tei:address> input) should be, and implement a fix. f) Test and update your fix until it works.[2] g) Validate the HTML produced.[3] h) Find any CSS files that may need to be changed accordingly, and change 'em as needed. i) Share your test file and solution. 4. On the call we will try to run each solution on someone else's test file(s). Notes ----- [1] https://github.com/TEIC/Stylesheets/issues/261 [2] E.g., by running /path/to/Stylesheets/bin/teitohtml TEST.xml [3] E.g., by opening in oXygen or by uploading to either https://validator.nu/ or http://validator.w3.org/.

5 4

tei down again?
by Mylonas, Elli 04 May '17

04 May '17

Can't reach it from Athens, trying to look things up in a workshop... --elli

2 1

Re: [tei-council] co-operative stylesheet education session #9
by Alejandro Bia 03 May '17

03 May '17

A few thoughts on the ticket #261 problem: As can be read in several placed on the Web: "the html:address element is ONLY for contact information for its nearest html:article or html:body ancestor" (article only exists in HTML5). In https://developer.mozilla.org/en/docs/Web/HTML/Element/address it also recommends that "to represent an arbitrary address, one that is not related to the contact information, use a html:p element rather than the html:address element." So html:p is a good candidate for the conversion, and a general-purpose one. INLINE vs BLOCK: So at this point my doubt is whether there are cases in TEI where a tei:address should be rendered "inline" (e.g. within a paragraph), instead of the perhaps more common "block" rendering (starting in a new line). If both renderings are expected in TEI, then we need an attribute to encode such difference and choose one option as the default (probably block). So we would have something like (I will use "rend" for the examples, buy can be any other attribute): TEI: Mary moved to <address rend="inline">32nd Moo street<address>, but before, she lived in <address rend="inline">23ed Miou street<address>. And for block rendered addresses, just use rend="block", or nothing if "block" is the default rendering. So a simple HTML rendering solution could be: In the case of inline-rendered addresses: HTML: Mary moved to 32nd Moo street, but before, she lived in 23ed Miou street. And for block-rendered addresses: TEI source: <address> <addrLine>110 Southmoor Road,</addrLine> <addrLine>Oxford OX2 6RB,</addrLine> <addrLine>UK</addrLine> </address> Should simply be converted to HTML like this: 110 Southmoor Road, Oxford OX2 6RB, UK And, when using more specific elements like tei:street, tei:name, etc., just the same thing: TEI source: <address> <street>110 Southmoor Road</street> <name type="city">Oxford</name> <postCode>OX2 6RB</postCode> <name type="country">United Kingdom</name> </address> Would be converted to HTML like this: 110 Southmoor Road Oxford OX2 6RB United Kingdom We could have differentiated renderings for street, name, postCode, etc., but I think this should be customized by projects themselves, and not be part of a general-purpose TEI stylesheet. Anyway, the output for differentiated rendering should be something like this: 110 Southmoor Road Oxford OX2 6RB United Kingdom Which is a very ugly HTML code (but better than using the HTML style attribute and have the CSS code embedded in the HTML target). "span" should be used since there are no HTML elements for street, postcode, city, country, etc. Once we have decided which will the HTML target solution be, the rest is coding an xsl:template and minimally modifying a CSS stylesheet. Alex.- At 22:18 03/05/2017, you wrote: >I've created a test file in case we still need one: >https://gist.github.com/raffazizzi/6b57a9c0016e46aebd249d5041ca4ae4 > >Raff > >On Wed, Apr 26, 2017 at 12:20 PM, Syd Bauman <s.bauman(a)northeastern.edu> >wrote: > > > 1. Andrew, Marcus, Jure, and Ron -- would you like to continue to receive > > these e-mails? If so, speak up. > > > > 2. We're scheduled to meet on Thu 04 May at 13:00Z on Google > > Hangouts. > > > > 3. Per our previous e-mail discussion, we have HOME WORK to complete > > before this meeting. Our goal is to address ticket #261.[1] > > > > a) Read the ticket.[1] > > > > b) Make a small test TEI file that uses the <tei:address> element; if > > you can do so easily, put it up somewhere to share with the rest > > of us for step #4, below. > > > > c) Make a fork of the Stylesheets repo. > > > > d) Find the 2 files that generate <html:address>, and fix the one > > that is general-purpose, leaving the the one that is used in > > the footer for later -- extra credit :-) > > > > e) Decide what the HTML output (for <tei:address> input) should > > be, and implement a fix. > > > > f) Test and update your fix until it works.[2] > > > > g) Validate the HTML produced.[3] > > > > h) Find any CSS files that may need to be changed accordingly, > > and change 'em as needed. > > > > i) Share your test file and solution. > > > > 4. On the call we will try to run each solution on someone else's > > test file(s). > > > > Notes > > ----- > > [1] https://github.com/TEIC/Stylesheets/issues/261 > > [2] E.g., by running /path/to/Stylesheets/bin/teitohtml TEST.xml > > [3] E.g., by opening in oXygen or by uploading to either > > https://validator.nu/ or http://validator.w3.org/. > > -- > > tei-council mailing list > > tei-council(a)lists.tei-c.org > > http://lists.lists.tei-c.org/mailman/listinfo/tei-council > > > > PLEASE NOTE: postings to this list are publicly archived > > >-- >tei-council mailing list >tei-council(a)lists.tei-c.org >http://lists.lists.tei-c.org/mailman/listinfo/tei-council > >PLEASE NOTE: postings to this list are publicly archived --------------------------------------------------------- ALEJANDRO BIA e-mail: abia(a)umh.es CIO - DEMI Centro de Investigación Operativa Departamento de Estadística, Matemáticas e Informática Área de Lenguajes y Sistemas Informáticos Universidad Miguel Hernández Ed. Torretamarit, Av. Universidad s/n, CP:03202, Elche, ESPAÑA Web: http://dhw.umh.es/alex-bia/ Tel: +34 966658973 Móvil: +34 644447008 Skype: alex-bia Twitter: @alex_bia --------------------------------------------------------- --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0