[tei-council] comments on ST

[Syd Bauman]

> This is on my list of last minute checking -- it's easy to check
> the word preceding <ptr> passim...

Roger-roger.


> "most any combination" is markedly AmE usage, and it does say "mix
> and match WITH". However, there's no need for the phrase following
> the comma anyway, so I've just deleted it.

Haven't addressed my complaint, that "mix and match" is a little
misleading, but it's a minor point.


> > * 4th para, last sentence, "... as well as to generate documentation
> >   such as the <title>Guidelines</title> and their associated
> >   website.": I'd like to shift the emphasis to the possibilities.
> >   Something more like:
> > 
> >      ... as well as to generate associated documentation in a variety
> >      of formats. (At the time of this writing TEI and XHTML formats
> >      are supported by TEI-supplied software.) The web-accessible
> >      version of these <title>Guidelines</title> is generated in this
> >      manner.
> 
> "At the time of this writing" is always a hostage to fortune. 

Granted. Would be better to avoid that.

> I don't think that this is the place to say more than it currently
> says.

I think this place either needs to say less:

     ... as well as to generate associated documentation. These
     <title>Guidelines</title> are generated in this manner.

or it needs to say more:

     ... as well as to generate associated documentation in a variety
     of formats, e.g. XHTML. The web-accessible version of these
     <title>Guidelines</title> is generated in this manner.


> " a formal declaration, expressed using a special-purpose XML
> vocabulary defined by these Guidelines in combination with elements
> taken from the ISO schema language RELAX NG"

Well said.


> There is a distinction being made between the "definition" and the
> "declaration" parts of the ODD. But I've now tried a rewrite.

OK, looking forward ...


> Will look into this. I thought it was in Utilities, but it isn't.

Check, standing by ...


> Dunno. Do FPIs have any future in XML?

Perhaps more importantly, a more precise question: Do FPIs have any
future in TEI? Again, these are not used anywhere except maybe to
stitch together DTD fragments, which we are not addressing in the
Guidelines. I'm inclined to nuke 'em.


> I am still not happy about the names of the modules, myself. So
> will try to come up with a revision that takes this into account.

I don't like the names, either. I also don't wonder if the name of
the module being declared by a chapter should be right up front, much
as the <!ENTITY % TEI.verse 'INCLUDE'> used to be right up front.
(Now it would be <memberOf key='verse'>, of course.)


> <p>For each module listed above, the corresponding chapter gives a
> full description of the classes, elements, and macros which it
> makes available when it is included in a schema. Other chapters of
> these Guidelines explore other aspects of using the TEI scheme.
> </p>

Much better. (Not even sure the 2nd sentence is needed.)


> Added this sentence:
> 
>   The method of doing this recommended by these Guidelines is to
> provide explicitly or by reference a TEI schema specification
> against which the document may be validated. </p>

Ah. Well. It is an improvement. Before we were implicitly not
providing any guidance, now we're explicitly providing useless
guidance. 


> ... and this isn't the heart, it's all there is of the schemaspec!

Umm, but a complete ODD needs a <TEI>, a <teiHeader>, a <text>, etc.

> "The simplest customization of the TEI scheme combines just the
> four recommended modules mentioned above. In ODD format, this
> schema specification takes this form:"

Yup, much better, thanks.


> Yes, this is confusing. I've moved the sentence about the @start to
> later in the paragraph.

OK, thanks.


> I would rather not go into the distinction between open and closed
> schema languages here. I have replaced "another" by "any other
> adequately powerful"

I agree it may not be a good idea to go into the closed / open
distinction here. But I'm a little worried that your suggested
phrasing would upset Schematroners worldwide. How about "any other
similarly powerful"?


> ...locations. In either case, an element is said to
> <term>inherit</term> properties from any classes of which it is a
> member. </p>
> 
> <p>Classes (and therefore elements which are members of those
> classes) may also inherit properties from other classes. For
> example, supposing that class A is a member (or a
> <term>subclass</term>) of class B, any element which is a member of
> class A will inherit not only the properties defined by class A,
> but also those defined by class B. In such a situation, we also say
> that class B is a <term>superclass</term> of class. The properties
                                                    ^ B
> of a superclass are inherited by all members of its subclasses.
> </p>

Much better, I think.


> Happy to nuke it right now, for 1.0. But we ought to get council to
> agree, no?

I suppose so, but Council and the editors never really agreed to have
it there in the first place.


> Should be mentioned, definitely, if it's global. But probably it
> should be in att.global.linking, and hence wouldnt be documented
> here but in SA. This would slightly limit the flexibility of your
> addressing capabilities unless that module was loaded, but maybe
> that's livable with?

Yes, I think xml:base= to SA is a good move. (Don't know why we
didn't think of that before!)


> OK. This brings us down to div5 or so, but what the hay.

2 more to go and still counting ... :-)


> I agree they should look consistent. I have left it as egXML though
> as otherwise we lose the bib reference.

Hmmm....


> > 
> > * //div[@xml:id='STGA']//x:egXML[2]: whole example and numbers in
> >   preceding sentence need to be replaced. 
> 
> Why? Nothing wrong with your proposed replacement but what's wrong
> with leaving things as they are? 

Well, it's just confusing in that it doesn't match the current
Guidelines at all, and skips 2-9.


> Is your replacement from some source where this kind of error
> actually occurred (in which case where?)

No. Although I can try to find a real example from the WWP if you
like. 


> We did discuss this on council list, and this proposal was the one
> accepted. I'd prefer not to reopen the discussion at this late
> stage.

I'm not sure if you mean mimeType= vs scheme= was discussed (in which
case that's just fine, leave as is) or open vs closed list. If the
latter, I apologize for missing this conversation, but could someone
provide a pointer to it?


> Well, I suppose we can indulge an old timer on this for once in a
> while. Actually, us old timers really prefer "typeface" as a single
> word.

Oooh, now you're dating yourself. Thanks.


> OK: inserted "For example," rather than "E.g." though.

Fine and dandy.


> > * <div><head>The Basic TEI Class Structure</head> is missing an
> >   xml:id=.
> 
> AIB? it has one now

I don't get the "AIB?" part. But you'll be amused to know that I
often find myself reading this as "The Basic TEI Class Struggle". :-)


> > * The <desc> of the data.pattern
> Please propose a rewording.

"indicates that the attribute value is a regular expression."?

> 
> > 
> > * The <desc> of the data.name tagdoc: change to
> >      <desc>defines the range of attribute values expressed as an <ref
> >        target="http://www.w3.org/TR/REC-xml/#dt-name">XML
> >        Name</ref></desc>
> > 
> 
> [data.name tagdoc:] Have added link to the tagdoc notes. House
> style deprecates use of hidden links in the body of text.

Sounds fine. Important part was to remove "or identifier" from <desc>.



> > * //div[@xml:id='DTYPES']/p[10] (right after the data.code
> >   <specDesc>): 
> >   1) "only attribute defined as of type": delete "of"
> 
> deleted "defined"


?? The sentence read 

   The attributes <att>key</att> provided by the <ident
   type="class">att.naming</ident> class is currently the only
   attribute defined as of type <ident
   type="datatype">data.key</ident>.

If you delete "defined" it's still nonsense. Need to make the 2nd
word "attributes" singular, and delete either "of" or "defined as",
no? (My guess is you corrected this properly, and mis-reported the
change you made, but since it's not checked in yet, I can't just look
and spare you this babble.)


> Formatting issue. I think it's useful, even in the case of this
> "module", meself.

I didn't say it's not useful, just that it shouldn't be here, in the
prose chapter. (It's not useful to the person who's *reading* the
prose, it's useful to the person who wants to look something up.)


> Deleted everything following first "... further discussed in
> chapter IM"

Good.