Re: [tei-council] rework of standoff proposal

I agree with Martin proposal, while I am not in synthony with the idea of keeping a standOffHeader because 1) if you want an autonomous standoff doc you need to put the TEIHeader to validate the file, so you would need to have both (unless we make TEIHeader optional) 2) standoffHdr=TEIHeader that is syntactic sugar: this is against Occam razor principle that I would follow as far as it is possible 3) people will start asking to add tags and features to this new element and the council will lose a lot of time refusing to add them or arguing if they are general enough to have them in the proposed macro... ... and some other odd feelings I cannot express clearly now F 2015-05-31 16:42 GMT+02:00 Martin Holmes :

I think it ought to have a ticket and at least a cursory yes from the rest of Council, don't you?

I'd put the proposed changes on a ticket along with the rationale, then do it if no-one objects. Then we'll have documented why we did it, for the benefit of future generations. Think of the children.

Cheers, Martin

On 2015-05-31 10:40 AM, Lou Burnard wrote:

...

+1 from me.

shall I have a crack at it?

On 31/05/15 15:39, Martin Holmes wrote:

...

Peter's point is a good one: if we do use teiHeader, we'll have to slightly revise its definition. But that's not too complicated. To be honest, you can already have a document that consists only of a teiHeader and a <fsdDecl>.

This of course means that the definition of model.resourceLike:

"groups non-textual elements which may appear together with a header and a text to constitute a TEI document."

is misleading, because it suggests you must have a <text>, which is not true.

So I think it's time to look at these core definitions and readjust them slightly to take account of the range of different sorts of thing that can constitute a standalone TEI file nowadays.

Cheers, Martin

On 2015-05-31 10:19 AM, Peter Stadler wrote:

...

I’m glad you like it :)

I’m d’accord with all of it but still feel a little bit uneasy about having teiHeader instead of standOffHeader because a teiHeader is „…making up an electronic title page for every TEI-conformant document.“ — and the standoff part does not need to be a TEI-conformant document (while it *can* be). So, I’d propose to keep the name standOffHeader and adjust the content model to macro.teiHeaderContent. (This macro is not in place yet but I think it’d be a good idea and it be constructed exactly as the current content model of teiHeader)

Best Peter

Am 31.05.2015 um 01:58 schrieb Laurent Romary

...

:

Dear all, I am really pleased that you managed to put this effort on this. The discussion on Friday showed that this is a conceptual move that the council had to make it its own thing (“s’approprier” in French).

Le 30 mai 2015 à 23:20, Peter Stadler a écrit :

...

Dear all,

a Council working group (PFS, LB, MH, FC, SM, PWS) just created an alternative proposal as the "Ann Arbor" branch at https://github.com/laurentromary/stdfSpec/tree/AnnArbor. The changes in detail:

* killed mapStruct

Indeed. We need to wait until we have an appropriate concept for this. I see Andreas this week and we’ll wrap on this.

* renamed annotationGrp —> listAnnotation

...

I’ll tell Thomas ASAP so that he can have the named changed on the current ISO proposal. Does the semantics ofxxxGrp reflects that there are heterogeneous content objects there? (typically components of the triptych target-annotation-body in OA)

* renamed model.annotationPart —> model.annotation

...

I wasn’t happy with the xxxPart here. Sounds good!

* got rid of dash in module name

...

I don’t really care :-} (reminds me of a song by Elton John on the “Single Man” album

* removed class att.confidence in favor of

...

https://sourceforge.net/p/tei/feature-requests/561/

I am looking forward to have this feature implemented.

* added some more elements to model.annotation

...

In any case this “module” is likely to be customized when used. It’s really open. So why not.

* removed standOffHeader in favor of teiHeader(!!)

...

Interesting… (not in the British sense). Let’s move ahead with this.

...

We did not update the examples yet.

That’s easy to do and I can contribute if there is a consensus on the above decisions.

...

I’m curious about Laurent’s reaction and will probably have a conf call in the next week with him (— Laurent?!)

Kudos to the council. How much of this can I take for stable in current implementations? Best wishes to all, Laurent

...

Best Peter

Laurent Romary INRIA laurent.romary@inria.fr

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- Fabio Ciotti Dipartimento Studi Umanistici, Università di Roma Tor Vergata Presidente Associazione Informatica Umanistica Cultura Digitale