[tei-council] Guidelines formatting

[Lou Burnard]

Let me make clear that I'm not objecting to the display of ancestor 
information as such. On the contrary I think this is a really important 
component of the reference documentation. What I'm objecting to is the 
flattened list of all possible ancestors in the current prototype. This 
can only confuse those people who are not immediately led to assume 
that  the TEI scheme is entirely mad because it allows (eg) a <stage> 
inside a <musicNotation>)

The most important thing we have introduced in P5 is the class system. 
It's the way we want people to understand the Guidelines, and it's the 
ONLY way they can effectively customize the system, which is one of our 
declared goals for P5. We've also put huge amounts of effort into 
getting the class system a bit more consistent and meaningful. So why 
don't we reflect that effort in this list? We give the class membership 
for elements separately from the parents: why not merge the two? why not 
format it in the same way as the Members list i.e. as className 
[classMemberList]?

It would also be good if the classMemberList were formatted differently, 
or displayed on a click, in both cases.

Secondly, in your comments below Chris you  recomment both that this 
full and flattened list of parents should be in the full documentation, 
and that it should be in the documentation for your own customization. I 
would support the second position, but not the first.


 Wittern Christian wrote:
> Lou Burnard wrote:
>> Sebastian Rahtz wrote:
>>> yes, the big day has arrived, at 
>>> http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml.ID=REFTAG
>>>
>>> you can see the parentage of elements, classes and macros. Now,
>>> I think its silly and unwieldy, but does it make  those people who
>>> have been asking for it for years happy?
>>>
>> This looks more than silly to me. Does anyone seriously want the 
>> Guidelines to look like this?
> Well, hum, yes!!  At least the reference section of the online version.
>>
>> It's  misleading too -- it implies that everyone will always be using 
>> teiall, and it doesn't indicate the macros and model classes which 
>> are what really determines parent/child relationships in the TEI 
>> model, so you can't use it to work out how you might customize the 
>> TEI properly.
> This will of course be generated from your personal ODD, including 
> only those elements you actually included, I am sure.
>
>>
>> I haven't heard people asking for this for years. In fact, the last 
>> time I remember any discussion of it  was many years ago, and the 
>> conclusion then was that it only made sense to produce this kind of 
>> listing for specific TEI schemas (the example then was tei lite, but 
>> now I guess we'd propose tei tite for this dubious privilege) and 
>> certainly not for the whole of the guidelines.
> I just recently heard two or three people lamenting about the lack of 
> this list within earshot.  Maybe I am socializing with the wrong 
> people.  But seriously, if there is doubt about it's usefulness, I 
> think this would be a good topic to solicit input from TEI-L via 
> surveymonkey (Although we might want to hold this off until we have a 
> complete proposal for layout features).
>
> Christian
>