dataypes: the never ending story
If we are to abide by Martin's eminently suggestion of permitting the new pure odd dataRef to coexist with the current <dataype> mechanism, I can't see any way out of doing the following a) make a set of new <dataSpec> elements corresponding with the existing <macroSpec type="dt">s b) since @ident values are supposed to be unique, these new things will all have to have different names (I suggest teidata.foo rather than data.foo) c) the current section 1.4.2 on datatype macros (#DTYPES, in #ST) will also need to be cloned, or substantially revised, since this is where the pesky things are actually defined Anyone got any better ideas?
On 15-06-08 01:15 PM, Lou Burnard wrote:
If we are to abide by Martin's eminently suggestion
You cunningly left the adjective for the reader to supply there, but I don't think we have any option here, do we? We have to deprecate anything we're going to remove for a period of two years, as Syd reminded me recently wrt the defaultVals.
of permitting the new pure odd dataRef to coexist with the current <dataype> mechanism, I can't see any way out of doing the following
I don't think I was suggesting that <datatype> and <dataRef> both be available in a Pure ODD structure, was I? I think I would have meant that the old mechanisms will have to continue to be supported almost indefinitely, but within Pure ODD structures it would be better to use only Pure ODD elements. Nevertheless, I think your three things below are still necessary.
a) make a set of new <dataSpec> elements corresponding with the existing <macroSpec type="dt">s
Makes sense to me.
b) since @ident values are supposed to be unique, these new things will all have to have different names (I suggest teidata.foo rather than data.foo)
Also nice and clear.
c) the current section 1.4.2 on datatype macros (#DTYPES, in #ST) will also need to be cloned, or substantially revised, since this is where the pesky things are actually defined
The chapter prose would have to be expanded anyway, wouldn't it? Cheers, Martin
Anyone got any better ideas?
On 08/06/15 21:41, Martin Holmes wrote:
On 15-06-08 01:15 PM, Lou Burnard wrote:
If we are to abide by Martin's eminently suggestion
You cunningly left the adjective for the reader to supply there, but I don't think we have any option here, do we?
the word i failed to type was, of course, "sensible"
We have to deprecate anything we're going to remove for a period of two years, as Syd reminded me recently wrt the defaultVals.
of permitting the new pure odd dataRef to coexist with the current <dataype> mechanism, I can't see any way out of doing the following
I don't think I was suggesting that <datatype> and <dataRef> both be available in a Pure ODD structure, was I? I think I would have meant that the old mechanisms will have to continue to be supported almost indefinitely, but within Pure ODD structures it would be better to use only Pure ODD elements
Not entirely sure what a "pure ODD structure" is, tbh, but clearly there's no reason for "pure odd" to continue to support legacy ways of doing things. Or we will never make any progress. And note that going over to using pure odd isn't going to affect the 95% of the TEI community which does not write its own ODDs.
. [...]
c) the current section 1.4.2 on datatype macros (#DTYPES, in #ST) will also need to be cloned, or substantially revised, since this is where the pesky things are actually defined
The chapter prose would have to be expanded anyway, wouldn't it? it
Or contracted. Don't forget there are two sections concerned: one where we talk about the ODD elements (#TD) and one where we actually say what datatypes the TEI provides (#DTYPES). I'm trying (but failing) to avoid having to double the size of the latter. For a moment I even toyed with the idea of abandoning those TEI dataypes which map directly onto an existing W3C schema datatype, since we can use dataRef to point specifically to the latter. But my better self wouldn't let me.
I'm confused, probably because I missed some part of important discussion. So apologies in advance, but it sounds like you're talking about having datatypes in the TEI Guidelines defined by both <datatype> and <dataSpec> simultaneously. This seems like overkill to me. While we are careful not to break backwards compatibility for TEI *users* w/o good reason and deprecation, we are all but outright hostile to TEI *customizers*, frequently changing classes out from under them w/o warning. Personally, my first reaction is that a (6-month) warning is a good idea, but otherwise we should go ahead and change our <datatype>s to <dataSpec>s. (Unless I'm missing something, here?) The TEI Guidelines and associated stylesheets need to support both during the deprecation period, of course, before <datatype> can be dropped from the Guidelines -- i.e., before the definition of <datatype> can be dropped from the Guidelines, as opposed to its internal use. BTW, is there a reason <datatype minOccurs="1" maxOccurs="3"> <rng:ref name="data.count"/> </datatype> should stop working when 'data.count' is defined by a <dataSpec> rather than a <macroSpec>? I had thought it would continue to work.
If we are to abide by Martin's eminently suggestion
You cunningly left the adjective for the reader to supply there, but I don't think we have any option here, do we?
the word i failed to type was, of course, "sensible"
We have to deprecate anything we're going to remove for a period of two years, as Syd reminded me recently wrt the defaultVals.
of permitting the new pure odd dataRef to coexist with the current <dataype> mechanism, I can't see any way out of doing the following
I don't think I was suggesting that <datatype> and <dataRef> both be available in a Pure ODD structure, was I? I think I would have meant that the old mechanisms will have to continue to be supported almost indefinitely, but within Pure ODD structures it would be better to use only Pure ODD elements
Not entirely sure what a "pure ODD structure" is, tbh, but clearly there's no reason for "pure odd" to continue to support legacy ways of doing things. Or we will never make any progress. And note that going over to using pure odd isn't going to affect the 95% of the TEI community which does not write its own ODDs.
. [...]
c) the current section 1.4.2 on datatype macros (#DTYPES, in #ST) will also need to be cloned, or substantially revised, since this is where the pesky things are actually defined
The chapter prose would have to be expanded anyway, wouldn't it? it
Or contracted. Don't forget there are two sections concerned: one where we talk about the ODD elements (#TD) and one where we actually say what datatypes the TEI provides (#DTYPES). I'm trying (but failing) to avoid having to double the size of the latter. For a moment I even toyed with the idea of abandoning those TEI dataypes which map directly onto an existing W3C schema datatype, since we can use dataRef to point specifically to the latter. But my better self wouldn't let me.
On 09/06/15 16:06, Syd Bauman wrote:
I'm confused, probably because I missed some part of important discussion. So apologies in advance, but it sounds like you're talking about having datatypes in the TEI Guidelines defined by both <datatype> and <dataSpec> simultaneously. This seems like overkill to me. While we are careful not to break backwards compatibility for TEI *users* w/o good reason and deprecation, we are all but outright hostile to TEI *customizers*, frequently changing classes out from under them w/o warning.
Um, I think we have done that precisely once, so far. Is that really very hostile ?
Personally, my first reaction is that a (6-month) warning is a good idea, but otherwise we should go ahead and change our <datatype>s to <dataSpec>s. (Unless I'm missing something, here?)
I think you may be.
BTW, is there a reason <datatype minOccurs="1" maxOccurs="3"> <rng:ref name="data.count"/> </datatype> should stop working when 'data.count' is defined by a <dataSpec> rather than a <macroSpec>? I had thought it would continue to work.
"data.count" is never going to be defined by a <dataSpec>. The proposal is to use a different name e.g. "teidata.count".
On 15-06-09 08:12 AM, Lou Burnard wrote:
On 09/06/15 16:06, Syd Bauman wrote:
I'm confused, probably because I missed some part of important discussion. So apologies in advance, but it sounds like you're talking about having datatypes in the TEI Guidelines defined by both <datatype> and <dataSpec> simultaneously. This seems like overkill to me. While we are careful not to break backwards compatibility for TEI *users* w/o good reason and deprecation, we are all but outright hostile to TEI *customizers*, frequently changing classes out from under them w/o warning.
Um, I think we have done that precisely once, so far. Is that really very hostile ?
We've made changes to classes a few times -- creating att.source and att.global.rendition are recent examples. The latter proved slightly inconvenient for customizers, but to be fair it was flagged well in advance, having arisen out of a lengthy discussion on TEI-L, and when I made the change initially (months before the actual release containing it) I announced it on TEI-L and suggested that customizers could get a preview of it from the Jenkins build. But it does sound like we need an explicit policy here. We have the policy that anything affecting validation undergo two years of deprecation before implementation; but we don't have any clear rules for changes affecting existing customizations.
Personally, my first reaction is that a (6-month) warning is a good idea, but otherwise we should go ahead and change our <datatype>s to <dataSpec>s. (Unless I'm missing something, here?)
I think you may be.
Changing what we do in the Guidelines is obviously step 1 (eating our own dog food). But I think we should probably be thinking along the lines of creating a page on the wiki which introduces and explains Pure ODD in detail, so that customizers can get a good early look at it before it's integrated into the Guidelines prose. Cheers, Martin
BTW, is there a reason <datatype minOccurs="1" maxOccurs="3"> <rng:ref name="data.count"/> </datatype> should stop working when 'data.count' is defined by a <dataSpec> rather than a <macroSpec>? I had thought it would continue to work.
"data.count" is never going to be defined by a <dataSpec>. The proposal is to use a different name e.g. "teidata.count".
On 09/06/15 16:28, Martin Holmes wrote:
Changing what we do in the Guidelines is obviously step 1 (eating our own dog food).
In which context, I have just noticed that the Guidelines are no longer valid, because the BIB file uses biblScope@type passim (instead of biblScope@unit) verb sap
File a bug. :-) On 15-06-09 08:33 AM, Lou Burnard wrote:
On 09/06/15 16:28, Martin Holmes wrote:
Changing what we do in the Guidelines is obviously step 1 (eating our own dog food).
In which context, I have just noticed that the Guidelines are no longer valid, because the BIB file uses biblScope@type passim (instead of biblScope@unit)
verb sap
Fixed it in the branch I am working on. Ars longa vita brevis. On 09/06/15 19:01, Martin Holmes wrote:
File a bug. :-)
On 15-06-09 08:33 AM, Lou Burnard wrote:
On 09/06/15 16:28, Martin Holmes wrote:
Changing what we do in the Guidelines is obviously step 1 (eating our own dog food).
In which context, I have just noticed that the Guidelines are no longer valid, because the BIB file uses biblScope@type passim (instead of biblScope@unit)
verb sap
"data.count" is never going to be defined by a <dataSpec>. The proposal is to use a different name e.g. "teidata.count".
I understand the proposal, but I don't get why. Why not just change the definition of 'data.count' from being declared with <macroSpec> to being declared with <dataSpec>?
Because then you can't have datatype and dataRef coexisting. On 09/06/15 17:19, Syd Bauman wrote:
"data.count" is never going to be defined by a <dataSpec>. The proposal is to use a different name e.g. "teidata.count". I understand the proposal, but I don't get why. Why not just change the definition of 'data.count' from being declared with <macroSpec> to being declared with <dataSpec>?
Hi Lou, On 15-06-09 07:24 AM, Lou Burnard wrote:
On 08/06/15 21:41, Martin Holmes wrote:
On 15-06-08 01:15 PM, Lou Burnard wrote:
If we are to abide by Martin's eminently suggestion
You cunningly left the adjective for the reader to supply there, but I don't think we have any option here, do we?
the word i failed to type was, of course, "sensible"
We have to deprecate anything we're going to remove for a period of two years, as Syd reminded me recently wrt the defaultVals.
of permitting the new pure odd dataRef to coexist with the current <dataype> mechanism, I can't see any way out of doing the following
I don't think I was suggesting that <datatype> and <dataRef> both be available in a Pure ODD structure, was I? I think I would have meant that the old mechanisms will have to continue to be supported almost indefinitely, but within Pure ODD structures it would be better to use only Pure ODD elements
Not entirely sure what a "pure ODD structure" is, tbh,
You're right, that's not really a meaningful concept. I was vaguely (as usual) thinking that there are Pure ODD ways of doing things and old ways of doing things and they're absolutely distinct, but of course they share most of their elements and have to coexist.
but clearly there's no reason for "pure odd" to continue to support legacy ways of doing things. Or we will never make any progress. And note that going over to using pure odd isn't going to affect the 95% of the TEI community which does not write its own ODDs.
I'm hoping it might reduce that 95% to 80%, eventually.
. [...]
c) the current section 1.4.2 on datatype macros (#DTYPES, in #ST) will also need to be cloned, or substantially revised, since this is where the pesky things are actually defined
The chapter prose would have to be expanded anyway, wouldn't it? it
Or contracted. Don't forget there are two sections concerned: one where we talk about the ODD elements (#TD) and one where we actually say what datatypes the TEI provides (#DTYPES). I'm trying (but failing) to avoid having to double the size of the latter. For a moment I even toyed with the idea of abandoning those TEI dataypes which map directly onto an existing W3C schema datatype, since we can use dataRef to point specifically to the latter. But my better self wouldn't let me.
I see what you mean. But you must introduce me to this better self. :-) Cheers, Martin
participants (3)
-
Lou Burnard -
Martin Holmes -
Syd Bauman