[romajs] macroSpec[@type='dt'] vs dataSpec
Hi all, I'm facing a bit of a conundrum related to datatypes and RomaJS and need your input. I'll try my best to explain it. 1. Currently, there are two ways of defining datatypes in ODD: macroSpec[@type='dt'] and dataSpec. Is macroSpec[@type='dt'] going to be deprecated, or are both systems going to be viable? 2. The TEI source, and therefore p5subset.xml currently defines datatypes BOTH with macroSpec[@type='dt'] (e.g. data.certainty) and dataSpec (e.g. teidata.certainty). Why? Is one going to go away eventually? 3. What should Roma do? This is a multifaceted problem, but let's focus on elementSpec/content for now since this is what I'm dealing with at the moment. 3a: when creating/editing a macroRef, Roma will list all macroSpecs for the @key value, including those with @type='dt'. I'm inclined to keep this, because likely people who created new datatypes (which does happen) have done so with macroSpec[@type='dt'] for a while before dataSpec (and after). 3b: a p5subset specific issue: unless the macroSpec/dataSpec duplicates are not fixed, users will see them both show up. I don't think this is good: new ODDs should use dataSpec/dataRef, right? But at the same time I don't want Roma to not be able to handle existing ODDs with macroRefs to datatypes. Help. Raff
Fast thoughts: 1. Yup. 2. Partially: <dataSpec> is (correctly) used for 'teidata.*' datatypes <macroSpec> is used (under depricatoin) for 'data.*' datatypes -- they expire in October <macroSpec> is used for 'macro.*' macros. (Should that be done w/ <dataSpec>? Idunno off top of head.) 3a. I disagree. When dealing w/ <macroRef>, I say consider only <macroSpec>s with type="pe". 3b. Yes, new Roma should not be able to handle existing ODDs that use <macroRef> to point to 'data.*' datatypes, thus forcing users to switch. (Which is good, as they will *have* to switch in 8 months, anyway.)
I'm facing a bit of a conundrum related to datatypes and RomaJS and need your input. I'll try my best to explain it.
1. Currently, there are two ways of defining datatypes in ODD: macroSpec[@type='dt'] and dataSpec. Is macroSpec[@type='dt'] going to be deprecated, or are both systems going to be viable?
2. The TEI source, and therefore p5subset.xml currently defines datatypes BOTH with macroSpec[@type='dt'] (e.g. data.certainty) and dataSpec (e.g. teidata.certainty). Why? Is one going to go away eventually?
3. What should Roma do? This is a multifaceted problem, but let's focus on elementSpec/content for now since this is what I'm dealing with at the moment.
3a: when creating/editing a macroRef, Roma will list all macroSpecs for the @key value, including those with @type='dt'. I'm inclined to keep this, because likely people who created new datatypes (which does happen) have done so with macroSpec[@type='dt'] for a while before dataSpec (and after).
3b: a p5subset specific issue: unless the macroSpec/dataSpec duplicates are not fixed, users will see them both show up. I don't think this is good: new ODDs should use dataSpec/dataRef, right? But at the same time I don't want Roma to not be able to handle existing ODDs with macroRefs to datatypes.
Hi Syd and James,
Thank, these are very helpful comments.
On Wed, Feb 7, 2018 at 7:04 PM, Syd Bauman
2. Partially: <dataSpec> is (correctly) used for 'teidata.*' datatypes <macroSpec> is used (under depricatoin) for 'data.*' datatypes -- they expire in October <macroSpec> is used for 'macro.*' macros. (Should that be done w/ <dataSpec>? Idunno off top of head.)
This is good to know, since I'm aiming at a first official release at the conference in Japan, so close enough to the cut off date to justify ignoring deprecated specs. <macroSpec type="pe"> should still be used for macro.* macros. Also to James's point:
I'd be perfectly happy for when I try to load an ODD into RomaJS that it complain and say the ODD uses old ways of doing things (such as RelaxNG, macroSpec for datatypes, etc.) and say those need to be fixed first or something.
Though I worry there might be some complaining from the community, I think this is fair enough and I'll continue working under this assumption. The system could always offer to attempt to convert the input file to pure ODD if we put together an XSLT able to do so (I think Lou had started one, but I remember having mixed results when using it to get MEI's ODD to Pure ODD -- it still isn't pure btw because PureODD doesn't support datatypes with numeric ranges and we may not be the only ones out there with this issue). Thanks again! Raff
participants (2)
-
Raffaele Viglianti -
Syd Bauman