<titlePage> canonical="false" by default: Re: [osis-core] osisCore.1.9.9 attached!

[Patrick Durusau]

Greetings!

Note, use of meaningful subject lines helps me sort all the posts on a 
given issue. Hint, hint.

I would say yes, <titlePage> should default to canonical="false". Have 
made the change but are there other opinions?

Hope the day is off to a great start!

Patrick

Todd Tillinghast wrote:
> Patrick,
> 
> Should <titlePage> be canonical="false" by default?  This would follow
> our general convention that a Bible could generally be encoded without
> having to specify canonical values.
> 
> Todd
> 
> 
>>-----Original Message-----
>>From: osis-core-admin@bibletechnologieswg.org [mailto:osis-core-
>>admin@bibletechnologieswg.org] On Behalf Of Patrick Durusau
>>Sent: Monday, October 20, 2003 5:28 PM
>>To: osis-core@bibletechnologieswg.org
>>Subject: [osis-core] osisCore.1.9.9 attached!
>>
>>Guys,
>>
>>osisCore.1.9.9 is attached!
>>
>>I reached Steve this afternoon and the schema reflects the following
>>resolution of the issues we had outstanding (otPassage and the regex
> 
> for
> 
>>subjects, osisIdentifier, POS, lemma and morph).
>>
>>On otPassage: Steve reminded me of why this appeared in osisCore.1.0
> 
> but
> 
>>not osisCore.1.1, our first official release.
>>
>>As you may recall, there were calls for elements such as ntProphecy
> 
> for
> 
>>passages in the OT and others. The proposed element otPassage is of a
>>similar nature. Note that publishers already distinguish several uses
> 
> of
> 
>>small caps and the same can be done with a type attribute of
>>"x-otPassage" for such material. If someone does not apply the proper
>>stylesheet, you get an incorrect result. Would be the same if I ignore
>>the level attribute on the <q> element and render everything with
> 
> double
> 
>>ticks.
>>
>>On the regex question:
>>
>>As Steve reminded me, the issue we have been discussing is really one
> 
> of
> 
>>data entry and/or presentation. Certainly fine for authoring software
> 
> to
> 
>>allow the entry of lemmas with a space, but when saving to a valid
> 
> list
> 
>>in XML, the spaces must be replaced by something, and the users manual
>>will say that underscores are the appropriate replacement. Same for
>>hyphens that the user sees when they enter their morphology.
>>
>>Recall that since the source of the lemma, morph, POS is known (one
>>presumes to not enter data of an unknown nature) then the data can be
>>transformed to be OSIS compliant in the XML file and displayed to the
>>user with whatever formatting is desired.
>>
>>We have already taken this step by not allowing the ":" character in
>>identifiers, since our John.1.1 is usually written John 1:1, that is
>>with a space and a colon.
>>
>>The downside to not doing this is that we can't have valid XML lists
> 
> of
> 
>>tokens.
>>
>>Note that we also would not be able to use annotateRef to point to
> 
> such
> 
>>an identifier, which would be a very powerful mechanism for discussing
> 
> a
> 
>>particular lemma, morph or POS.
>>
>>The prefix is required and all prefixes must correspond to a work
>>element in the header. An open question is whether we should define
> 
> some
> 
>>standard work elements for a number of the usual systems so people can
>>simply paste them into their documents.
>>
>>Note that this means, at least the way I read it, that we no longer
> 
> list
> 
>>ISBN, etc. or the various subject catalogs. Just declare them in a
> 
> work
> 
>>element, which gives you more detail, versioning, etc., than we could
>>provide in the bare listings I had as attribute values.
>>
>>I realize that the foregoing may mean some changes in current
> 
> processing
> 
>>practices but in the longer run, OSIS documents will be valid XML and
>>able to take advantage of new XML tools as they emerge.
>>
>>For anyone who is interested, part of my rant, assuming it is accepted
>>for XML 2003, is how markup trees are actually a "presentation" of
>>markup. ;-)
>>
>>Really do appreciate all the thought and work that has gone into all
> 
> the
> 
>>  phone calls that everyone has tolerated so well and all the various
>>email posts. I really do read all of them, I really do, but sometimes
> 
> I
> 
>>can't respond on all of them. Your hard work has earned all of you
> 
> stars
> 
>>in your crowns in Heaven. (An old Southern saying. First time I heard
> 
> it
> 
>>was from a person I respected a great deal about something I had
> 
> really
> 
>>given no thought to doing. It just needed to get done. Something to go
>>with all the chains that I have forged link by link I suppose. ;-)
>>
>>At 11+ hours now so I am going to sign off.
>>
>>Hope everyone is having a great day!
>>
>>Patrick
>>--
>>Patrick Durusau
>>Director of Research and Development
>>Society of Biblical Literature
>>Patrick.Durusau@sbl-site.org
>>Chair, V1 - Text Processing: Office and Publishing Systems Interface
>>Co-Editor, ISO 13250, Topic Maps -- Reference Model
>>
>>Topic Maps: Human, not artificial, intelligence at work!
> 
> 
> _______________________________________________
> osis-core mailing list
> osis-core@bibletechnologieswg.org
> http://www.bibletechnologieswg.org/mailman/listinfo/osis-core
> 


-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
Patrick.Durusau@sbl-site.org
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model

Topic Maps: Human, not artificial, intelligence at work!