[tei-council] review of IM

[Syd Bauman]

[originally sent 2007-10-28 15:03 -0400]

> > The entire section does not mention the inclusion of Schematron
> > rules in an ODD, nor their extraction.
> >   
> Work for 1.1 I think

Well, a first draft is written, and is appended, below. [NOT! -- will
try sending shortly as a message, not an attachment --sb]


> > * Passim: very often the adjectival "firstly", "secondly", and
> > "thirdly" are used where I think we usually use "first",
> > "second", and "third".

> I can't find any non-adjectival uses of "first" "second" etc. And I
> find "firstly" "secondly" used in four different chapters, so I am
> not planning to change this

I count 10 occurrences of "firstly" in the entire Guidelines
(including comments, etc. -- just a grep), including two in this
chapter. I count well over 400 occurrences of "first", and a glance
says the majority (at least, a majority of the 30 or so in the middle
I scanned :-) are used the same way we are using "firstly" here.

I claim our implicit editorial style is to use "first", etc. 


> > * #IM/p[4]: deserves a re-write; here's a starting point:
> >             ...
> OK: I've reworded this and preceding para:

Yup, that's good.

> > * #IM-unified/p[1], 1st sentence, "... which specifies the name and
> > ...
> >       <p>Merging an ODD customization with the TEI P5 ODD
> > ...

> I've included this, tho it is a bit repetitious, given that the
> specDesc will generate the same info

Yeah, it is. Can we not put ident= on the atts= of that <specDesc>?
Do we want all the attrs other than ns= and ident=? Not to worry, the
info is there, even if a bit verbose.


> > * #IM-unified/p[1], 2nd sentence (pre-list): should perhaps a bit
> > ...
> Rewritten as
> ...

Perfect.


> I've adopted most of your rewording, but I am puzzled by the use of
> "<label> here. Is it meant to be a ordered list or a gloss list?
> I've assumed the latter.

Yes, I meant a glossed list. The "ordered" was left only because I
failed to notice it, let alone delete it!


> added a clause saying it';s an error to add something that already
> exists (but not saying what you should do in such a situation)

Looks good.


> > * #IM-unified/p[3]/list[1]/item[1]: Last I knew, this included the
> >   ...
> Not sure what you're proposing here

I could try to explain what I meant, but on re-reading and testing I
think it should be left as is, at least for now.


> > * #IM-unified/p[3]/list[1]/item[3], parenthetical: missing ", and",
> >   ...
> surely this ought to refer to the classes rather than to the elements? 
> it does now.

Sure! So long as they line up, that's great.


> > * #IM-unified/p[3]/list[1]/item[4]: "i.e." -> "e.g."; make
> >   "attribute" plural:
> >      <item>identified objects (i.e. those with an <att>ident</att>
> >      attribute, e.g. <gi>attDef</gi> and <gi>valItem</gi>) are
> >      processed according to their <att>mode</att> attributes,
> >      following the rules in this list.</item>
> >   It would be better, I think, to reword the whole list to use
> >   singular subjects, e.g. "Each object which can occur ... is taken
> >   
> The list does need rewording: I've had another crack at it, and
> reordered it slightly.

"... <gi>attDef</gi> and <gi>valItem</gi>. A components of this type"
                                                      ^
                                                      nuke


> its not the novelty that matters, it's the completeness, so i
> changed to "completely"

Good point!


> > but moreover, why is it
> >   easier to deal with multiple examples? 
> Probably because they're less confusing than multiple glosses. Have
> reworded the para anyway.

'Tis better, but I still find the concept a bit weird.


> >   "is itself inside an <gi>zeroOrMore</gi> inside a
> >   <gi>group</gi>": the "an" should be an "a".
> except that it's now aN <gi>rng:zeroOrMore</gi>  i think!

Uhhh ... right. I meant that the "a" should be an "an" (before what
is now <gi>rng:group</gi>). This is one of those cases where that
little carat technique would have done me well!


> > * #IMGS/p[3]: if the rewrite of the beginning of para 2 is accepted,
> >   #then this should be deleted.
> I dont see why

I think there was a different suggested rewrite of para 2 at one
point, but I reworded it again. Ignore.


> > * #IMGS/p[4], last sentence: is "Roma processors" (plural) correct?
> >   ...
> I wonder if this para is a hostage to fortune: it says "the TEI
> project" (whatever that is) will generate both parameterized and
> non parameterized schemas, which I thought we'd decided we didn't
> want to guarantee.

I think it's at least a bit problematic, if not outright a bad idea.

>  
> > * #IMGS/p[5]/eg[1] and eg[2]: Since there is no markup in the
> >   examples, the CDATA marked sections are superfluous.
> >   
> I think it's needed to stop the stylesheet filling and wrapping the lines
> > * #IMGS/p[5] text in between the two <eg>: The idea that "the
> >   knowledge that the attributes such as <att>n</att> and
> >   <att>rend</att> come from the global attribute class is lost" seems
> >   pretty counter-intuitive: everyone and anyone can see that n= and
> >   rend= come from the global attribute class, because the patterns
> >   used are named "att.global.n" and "att.global.rend". Here is a
> >   suggested re-wording:
> >     In the above, a redefinition of an attribute class will have no
> >     effect, as each class has already been expanded to its
> >     constituent attributes.
> >
> >   
> Have revised this, hopefully clearer now!

Maybe, but has problems:

   In the above, a subsequent redefinition of the attribute class
   (such as <ident type="class">att.global</ident>) would have no
   effect, since references to such classes have been expanded to
   reference their constituent attributes.

If you want to leave the parenthetical example in, the definite "the
attribute class" should be come indefinite: "an ...". Also, there's
number disagreement in the last clause. But I'd swap the
singular/plural of it anyway, thus:

   In the above, a subsequent redefinition of an attribute class
   (such as <ident type="class">att.global</ident>) would have no
   effect, since each reference to such a class has already been
   expanded to references to its constituent attributes.


> I had a stab

Still not great, but definitely better.


> > * IMGS/p[8], rest of para: Why are we recommending this only for
> >   DTDs? Just because it is hard for us to do for RELAX NG doesn't
> >   mean we should not recommend ODD processors do this.
> >   
> I'm confused didn't we discover that this was actually *illegal*
> for W3C Schema? so why are we doing it? I've commented that para
> out for now.

Well, if you're going to delete all the how-to stuff, you may as well
delete the explanatory stub ("Finally, an application ... in their
requirements.")

But I don't think there's really any problem, here. Yes, it is
illegal in W3C Schema to declare this attr, but the instructions are
suggesting it be declared for DTDs and RELAX NG, and not W3C Schema.
(And even points out that you have to generate this decl in RNG
*after* you've generated the XSD from the RNG.)


> yup. Did you know that Oxford's web site house rules have just
> banned the oxford comma? But I digress.

Say it isn't so! Ridiculous.


> > * #IM-naming/p[1]/list/item[3], 2nd sentence: suggested re-wording:
> >  ...
> >   Note that this does not give advice on what to do when there
> >   are two or more with the same value of xml:lang=. Fodder for a
> >   1.1 improvement.
> Have had a stab at that too!

Ummm ... where? (Don't bother answering right away.)


> > * #IM-naming/p[2]/list/item[2]: there is an exception: colons are
> >   removed first, so that the namespace prefix and attribute name are
> >   run together, as in 'att.global.attribute.xmlid'.
> i think this only applies to xml: though?

Yes and no. I think it applies to all namespace-prefixed attributes,
of which we (currently) only have "xml:". One could imagine having
xlink:href=, someday (ick!). And now that conformance requires
different namespace for added stuff, there will be lots of attrs in
other namespaces in customization ODDs.


> > * #STPE: This section deals with instructions on how to "stitch
> 
> It has to go somewhere. I don't recall Council saying it should be
> excluded from the Guidelines entirely; only that it should be moved
> out of ST (which it has been). If you're doing anything with the
> XML DTDs you need to know about this stuff. Iff we remove support
> for XML DTDs, we can certainly remove it, but not (I fear) before.

?? I need these instructions for DTDs no more than I need them for
RELAX NG. I go to Roma, submit my customization, click Schemas,
choose DTD, and Presto! I have a flattened DTD. No needlework
required.

But I don't honestly remember -- you may be right that Council wanted
it shoveled out of ST, not deleted.