Lou Burnard wrote:
> 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...

> 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
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?
> - 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 
> 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">

> 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  states 
" 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 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?


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 ?


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 ?

*<quote who>?
Why is there no "who" (ascribed) attribute on <quote>, though it is on 
<q>? Submit it to ?


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?

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

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:

       <resp>with help from <name>John Doe</name> in correcting Chapter 
Should I submit this to ?


*At 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 
more up-to-date apparently than those at ?

thanks and best wishes,