I too see nothing wrong with the second example,* only with the third.
(* Except for that incorrect use of an id what starts with a number)
On 4/2/2012 3:13 PM, O'Donnell, Dan wrote:
> I disagree that your second example is bad. It would be a little different to render if you think that all ptr must render to html:a, but not insurmountable. But I'd say even then it is an example that degrades well if you don't render the pointers and it could be an example of project-internal ise.of ptrs you don't intend to render.
>
> The text without ptr in your second example is simply a prose reference to a specific place in a manual. Your ptrs mark places where some other file location is relevant. It might make more sense to surround the words with ref. But using ptrs is.not crazy.
>
> Sent from my Samsung Captivate(tm) on Rogers
>
> "John P. McCaskey"<[log in to unmask]> wrote:
>
> Given this to encode:
> See the Manual, Ch. 1 "Installation," page 3.
> These would be fine:
> See the
> <ref @target="#M">Manual,</ref>
> <ref @target="#I">Ch. 1 "Installation,"</ref>
> <ref @target="#3">page 3.</ref>
>
> See the
> <ptr @target="#M" />Manual,
> <ptr @target="#I" />Ch. 1 "Installation,"
> <ptr @target="#3" />page 3.
> This would be bad:
> See the
> <ptr @target="#M" />Manual,
> <ptr @target="#I" />Ch. 1 "Installation,"
> page<ptr @target="#3" />.
> How should the two uses of<ptr> be disambiguated -- the one where<ptr> just points, and one where the contents of what is pointed at must somehow be represented for the text to be complete?
>
> Possibilities:
> - Make the semantics of<ptr> project-specific and then just be consistent.
> - Add a flag to<ptr> that indicates which meaning is intended.
> - Create some third element<point-follow-retrieve-and-include>.
> - Adopt the convention that an empty<ref /> means what is referred to is integral to the text.
>
> The last would produce this:
> See the
> <ref @target="#M">Manual,</ref>
> <ref @target="#I">Ch. 1 "Installation,"</ref>
> <ref @target="#3" />
> -- JPM
>
>
> On 4/2/2012 1:56 AM, Sebastian Rahtz wrote:
>
> I do agree that the examples of<ptr> have the potential to confuse, as they mix born-digital encoding
> with transcription encoding. Leaving that aside, though, the processor which wants to handle arbitrary
> TEI XML texts does not have _that_ hard a task to decide how to handle<ptr>. You basically follow the link
> and ask the object you arrive at what its title is. so
>
> * a web site may return its URL or a head/title element from its HTML
> * a div/list/table in TEI may return its<head>
> * a<biblStruct> may return "Author, Year" or [33] depending on desired style
> * any of them may return their page number, if you are in print mode.
>
> etc.
>
> But these "rules" are not written down by the TEI. One of us could propose such a rule
> set for adoption, an algorithm we can all implement, and that would be nice.
> --
> Stormageddon Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> Sólo le pido a Dios
> que el futuro no me sea indiferente
>
>
>
>
|
