[osis-core] osisCore.1.9.9 attached!

[Todd Tillinghast]

Patrick,

Same as below for subjectCT.

Todd

> -----Original Message-----
> From: osis-core-admin@bibletechnologieswg.org [mailto:osis-core-
> admin@bibletechnologieswg.org] On Behalf Of Todd Tillinghast
> Sent: Tuesday, October 21, 2003 6:21 PM
> To: osis-core@bibletechnologieswg.org
> Subject: RE: [osis-core] osisCore.1.9.9 attached!
> 
> Patrick,
> 
> Shouldn't the following:
> 	<xs:complexType name="identifierCT">
> 		<xs:simpleContent>
> 			<xs:extension base="xs:string">
> 				<xs:attributeGroup
> ref="globalWithoutType"/>
> 				<xs:attribute name="type"
> type="osisGenType"/>
> 				<xs:attribute name="canonical"
> type="xs:boolean" use="optional"/>
> 			</xs:extension>
> 		</xs:simpleContent>
> 	</xs:complexType>
> be:
> 	<xs:complexType name="identifierCT">
> 		<xs:simpleContent>
> 			<xs:extension base="osisGenType">
> 				<xs:attributeGroup
> ref="globalWithType"/>
> 				<xs:attribute name="canonical"
> type="xs:boolean" use="optional"/>
> 			</xs:extension>
> 		</xs:simpleContent>
> 	</xs:complexType>
> 
> 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