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 * renamed annotationGrp —> listAnnotation * renamed model.annotationPart —> model.annotation * got rid of dash in module name * removed class att.confidence in favor of https://sourceforge.net/p/tei/feature-requests/561/ * added some more elements to model.annotation * removed standOffHeader in favor of teiHeader(!!) We did not update the examples yet. I’m curious about Laurent’s reaction and will probably have a conf call in the next week with him (— Laurent?!) Best Peter
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
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
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
+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
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
I was about to do precisely that. Maybe I should have come down to the lobby to suggest it! On 31/05/15 15:42, Martin Holmes wrote:
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
Anyone for adding <text> to model.resourceLike and simplifying the content model of <TEI> accordingly? On 31/05/15 15:44, Lou Burnard wrote:
I was about to do precisely that. Maybe I should have come down to the lobby to suggest it!
On 31/05/15 15:42, Martin Holmes wrote:
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
It _sounds_ like a good idea, but... Will we break existing ODDs somehow? On 2015-05-31 10:49 AM, Lou Burnard wrote:
Anyone for adding <text> to model.resourceLike and simplifying the content model of <TEI> accordingly?
On 31/05/15 15:44, Lou Burnard wrote:
I was about to do precisely that. Maybe I should have come down to the lobby to suggest it!
On 31/05/15 15:42, Martin Holmes wrote:
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 > > > >
There is a (probably) related ticket: http://sourceforge.net/p/tei/feature-requests/501/ I’m happy to hand this over to Lou! Peter
Am 31.05.2015 um 10:52 schrieb Martin Holmes
: It _sounds_ like a good idea, but...
Will we break existing ODDs somehow?
On 2015-05-31 10:49 AM, Lou Burnard wrote:
Anyone for adding <text> to model.resourceLike and simplifying the content model of <TEI> accordingly?
On 31/05/15 15:44, Lou Burnard wrote:
I was about to do precisely that. Maybe I should have come down to the lobby to suggest it!
On 31/05/15 15:42, Martin Holmes wrote:
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
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
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
Le 31 mai 2015 à 16:57, Fabio Ciotti
a écrit : 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)
Of course, this is the idea of having stand-off annotations +in complement+ to a normal document with the TEI header etc.
2) standoffHdr=TEIHeader that is syntactic sugar: this is against Occam razor principle that I would follow as far as it is possible
Agree. The reason why we had a specific construct is that we wanted to have a light and flexible header.
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…
Or the council is benevolent (as ever) and understand the need to add things there ;-)
... and some other odd feelings I cannot express clearly now
F
2015-05-31 16:42 GMT+02:00 Martin Holmes
mailto:mholmes@uvic.ca>: 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
mailto:laurent.romary@INRIA.FR>: 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
mailto:stadler@edirom.de> 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 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/ 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 mailto:laurent.romary@inria.fr
-- tei-council mailing list tei-council@lists.tei-c.org mailto:tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council 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
Laurent Romary INRIA laurent.romary@inria.fr
Le 31 mai 2015 à 16:19, Peter Stadler
a écrit : 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).
I perfectly understand.
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)
I would favor this option (= standOffHeader) but then having a looser model (with everything being optional) could be great. It would also cover Lou’s scenario (if I have understood his concern correctly) where most things are in the main TEI document header, and only the additional specificities are stated in the standOffHeader. Cheerio, Laurent
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
Laurent Romary INRIA laurent.romary@inria.fr
participants (5)
-
Fabio Ciotti
-
Laurent Romary
-
Lou Burnard
-
Martin Holmes
-
Peter Stadler