Print

Print


Lou Burnard wrote:
[log in to unmask]" type="cite">Brett Zamir wrote:


However, I would still like to know why xs:Name is the type of choice here... For what good reason do these attribute values need to be xs:Name? I could understand if they should be NMTOKENS (plural) since that can allow multiple values and is looser than xs:Names (plural) (I've suggested this in a previous email but haven't gotten any responses on that one), but the only reason I can think of that a type should be constrained to xs:Name is if that attribute value might itself be converted into an XML element. Is that a common need?



Apologies for having overlooked your earlier question.
Not at all... I appreciate your guys' very high degree of responsiveness and excellence... I can only hope my questions and suggestions may contribute something small back...

I am attaching my other as yet unanswered questions again though, as I'd really, really like some finality on them, given that they are the only thing remaining toward our project's finishing validation for now...

[log in to unmask]" type="cite">The rationale such as it is is as follows:
-- things identified as data.enumerated  map to xs:Name because they are typically coded values
-- if they are coded values they will usually be decoded by reference to a <valItem> which has an @ident bearing the value concerned. That attribute is defined as data.name
Couldn't <valItem> also be defined as xs:token? Again, what is the use of constraining things to an xs:Name, unless it might itself become an XML element?
[log in to unmask]" type="cite">- if there is the possibility that multiple values may be needed as the value for an attribute of type data.enumerated, this is indicated by the @maxOccurs attribute of its <datatype> element.

If it can allow more than one, is that usually done through space delimiting?
[log in to unmask]" type="cite">If there are cases where you think the default value for this attribute (1)  is wrong, please shout now!

If you mean maxOccurs, yes, I think almost any item could ideally allow more than one item in an attribute. <editor role> for example, or @type in att.typed (such as used in div3):

        <editor role="compiler translator">

[log in to unmask]" type="cite">The argument was made, quite forcibly I think, that we should avoid the inherent ambiguity in allowing spaces within attribute values. We want to know that "foo bar" is actually ((foo)(bar)) and not (foo bar)!


I can see that. That could be solved though by using something such as a comma, or if commas could be allowed as part of the attribute, then something less common like the pipe ("|") symbol for delimiting. I know the schemas can use regular expressions in their definitions, so any delimiter should be possible.


General Diacritical Mark-up


As far as my earlier question looking for a generic tag which could be used to markup elements which need to be converted to a transliterated form later, I think <w> may serve our needs the best, especially given the useful @lemma attribute and our ability to use @type on it as well as use the element in any place where plain text was allowable.


The following is a repost of most of my earlier questions...
------------------------------------------------

Documentation on global elements

Along the lines of some of the items mentioned in my recent post "Misc. questions / suggestions - 1", I've noticed that while the documentation for http://www.tei-c.org/P5/Guidelines/ref-model.global.html  states "model.global groups empty elements which may appear at any point within a TEI text", tags such as <figure> and <bibl> (which are in the list) really cannot just go anywhere, such as in opener, closer, etc. (though we'd like to use them that way).

--------------------------------------------
More general use of <meeting> tag proposal

I was not aware of <rs> or even <name type>, so I think that might do the trick, though can I go ahead and suggest at http://sourceforge.net/tracker/?group_id=106328&atid=644065 that <meeting> being available in places like opener/closer/byline? I'd like to stick to the default as much as possible.
--------------------------------------------

<cit> documentation issue

The documentation states "Must contain a single quote and a single bibliographic reference in either order", but the schema doesn't actually constrain one in this way...

---------------------------------------------

I've basically finished a complete migration of our documents from P4 to P5, helped out a great deal by Sebastian's p4top5.xsl stylesheet. However, a number of issues came out for which I was wondering whether I could get clarification and/or make requests that P5 support the following in the future?


<figure>

After reviewing our documents, it seems there are qutie a few places where <figure> is not allowed but would come in handy: in a docTitle, within a byline, closer, or after a closer (as in a div3), or even within a <bibl>.

Should I submit these suggestions to http://sourceforge.net/tracker/?group_id=106328&atid=644065 ?


<bibl>

While I received some very helpful (though, in our case, not fully adequate) workarounds before from you all for this, might a new version of TEI P5 consider allowing <bibl> within closer and byline (it can be useful to have the author spelled out, for example). We had this need quite a bit within our documents, since we are to be be pretty aggressive in including <bibl>'s.

Should I submit this suggestion to http://sourceforge.net/tracker/?group_id=106328&atid=644065 ?


<quote who>?

Why is there no "who" (ascribed) attribute on <quote>, though it is on <q>? Submit it to http://sourceforge.net/tracker/?group_id=106328&atid=644065 ?


<respStmt>

While always having <resp> before or after <name> might work in English (though not necessarily if the prose is unconventional), is the current definition for <respStmt> too confining?

For example, we had this case. I know it could be broken up into two <respStmt>'s, but it seems they should be in one, no?

<editionStmt>
    <edition>George Ronald, publisher</edition>
    <respStmt>
        <resp>by</resp>
        <name>Mirza Zarqani</name>
        <resp>Translated by</resp>
        <name>Mohi Sobhani</name>
        <name>Shirley Macias</name>
    </respStmt>
</editionStmt>

I can also see the current constraints of <resp>+, <name>+ or <name>+, <resp>+  potentially causing problems when the text doesn't follow as planned (and maybe even causing problems in some languages which required content at the beginning and ending?)

For example, I can envision situations like this:

    <respStmt>
       <resp>with help from <name>John Doe</name> in correcting Chapter 7</resp>
    </respStmt>
  
Should I submit this to http://sourceforge.net/tracker/?group_id=106328&atid=644065 ?

<docAuthor>

At http://www.tei-c.org/P5/Guidelines/ref-byline.html it is stated that "docAuthor" can only be in a byline if it is on the title page. Is the "title page" a technical term referring to titleStmt, etc., or is it somewhat flexible where it can appear (such as at the beginning of a preface). If so, then this is not a constraint imposed by the schema, right?

Minor issue with placement of tags

I ran into a few cases where, although it was easy enough to fix, it didn't seem quite semantically correct.

For example, we had a page break in the middle of a <listBibl> which didn't validate. Putting the <pb/> at the beginning of the individual <bibl> worked out ok, but it seems the page break wasn't really breaking in the middle of that particular <bibl/>. Likewise, with a <figure> not being allowed to appear before a <head>. It was ok to put the <figure> at the beginning of the <head>, but the <figure> wasn't really in the heading area--it just happened to precede the section.

I know this is pretty minor, but thought I'd bring it up anyways.

One last question... Why are the Guidelines at http://tei.oucs.ox.ac.uk/ more up-to-date apparently than those at http://www.tei-c.org/ ?

thanks and best wishes,
Brett