Comment on duration format for WallDuration and CpuDuration
Hello, I would like to comment on the proposed format for the WallDuration and CpuDuration properties in the Usage Record - Format Recommandation. "The lexical representation for duration is the [ISO 8601] extended format PnYn MnDTnH nMnS, where nY represents the number of years, nM the number of months, nD the number of days, 'T' is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds. The number of seconds can include up to 6 decimal digits." If you want to convert this into seconds, or add this kind of duration to a grand total it is unclear how long a month is or a year. Is a month 30 ,31 or 28 days ? And a year is that 365 or 366 days? The use of years and months in this representation only give rise to needless uncertainties. Therefore I think it is better to use as duration format the number of seconds, with six decimal digits, or of you still want to use the ISO8601 standard, use it with the restriction that years and months will never be used. In that case it is always possible to convert it unambiguously to seconds. Bart Heupers, HPC Advisor SARA, Kruislaan 415, 1098 SJ Amsterdam
Comments from the rest of the group? Should we put some sort of sanity-checking limit on durations so that they make sense? If so, how should it be phrased & specified in the XML? Thx LM ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Laura F. McGinnis, Project Coordinator Data & Information Resource Services Pittsburgh Supercomputing Center email: lfm@psc.edu 300 South Craig St, #313 phone: 412-268-5642 Pittsburgh, PA 15213 fax: 412-268-5832 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message----- From: ur-wg-bounces@ogf.org [mailto:ur-wg-bounces@ogf.org] On Behalf Of Bart Heupers Sent: Wednesday, September 20, 2006 9:29 AM To: ur-wg@ogf.org Subject: [UR-WG] Comment on duration format for WallDuration and CpuDuration
Hello,
I would like to comment on the proposed format for the WallDuration and CpuDuration properties in the Usage Record - Format Recommandation.
"The lexical representation for duration is the [ISO 8601] extended format PnYn MnDTnH nMnS, where nY represents the number of years, nM the number of months, nD the number of days, 'T' is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds. The number of seconds can include up to 6 decimal digits."
If you want to convert this into seconds, or add this kind of duration to a grand total it is unclear how long a month is or a year. Is a month 30 ,31 or 28 days ? And a year is that 365 or 366 days?
The use of years and months in this representation only give rise to needless uncertainties.
Therefore I think it is better to use as duration format the number of seconds, with six decimal digits, or of you still want to use the ISO8601 standard, use it with the restriction that years and months will never be used. In that case it is always possible to convert it unambiguously to seconds.
Bart Heupers, HPC Advisor SARA, Kruislaan 415, 1098 SJ Amsterdam -- ur-wg mailing list ur-wg@ogf.org http://www.ogf.org/mailman/listinfo/ur-wg
Folks: I'm a normally quiet participant in your efforts. I support the idea of limiting duration units of measure to something that is translatable between your units of measure. To rephrase, measuring in hours, minutes or seconds is something I value from my many years of experience in rating (charging) and billing. I suggest you avoid days, months, and years. Days aren't always 24 hours long because of the many forms of daylight savings. Perhaps you may avoid DST, but I'd still urge you to avoid the use of days. Months and years have similar problems with varying size. Having said that, I can think of times when days, months and years are used in billing. In this context billing refers to the whole charges for a period of usage (day, month, ...). Rating (charging) refers to the charge for a specific event of usage/service. The situations that are day-friendly are usually in situations where you have memberships, rights, or other relationships. These come with increasing complications in the calculation of charges. You then have to have pro-ration algorithms when you have mid-period start and stops of these relationships. Just look at what happens with your wireless bills. If you expect that you are charging for relatively short durations, make your life much easier by using hours, minutes and seconds. Warmest Regards, Carl A. Wright Service Level Corporation +1 734-827-2000 ext. 219 (voice) +1 734-827-2200 (fax) http://www.servicelevel.net/ -----Original Message----- From: ur-wg-bounces@ogf.org [mailto:ur-wg-bounces@ogf.org] On Behalf Of Laura F McGinnis Sent: Wednesday, September 20, 2006 2:26 PM To: 'Mailing List for UR-WG' Subject: Re: [UR-WG] Comment on duration format for WallDuration andCpuDuration Comments from the rest of the group? Should we put some sort of sanity-checking limit on durations so that they make sense? If so, how should it be phrased & specified in the XML? Thx LM ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Laura F. McGinnis, Project Coordinator Data & Information Resource Services Pittsburgh Supercomputing Center email: lfm@psc.edu 300 South Craig St, #313 phone: 412-268-5642 Pittsburgh, PA 15213 fax: 412-268-5832 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message----- From: ur-wg-bounces@ogf.org [mailto:ur-wg-bounces@ogf.org] On Behalf Of Bart Heupers Sent: Wednesday, September 20, 2006 9:29 AM To: ur-wg@ogf.org Subject: [UR-WG] Comment on duration format for WallDuration and CpuDuration
Hello,
I would like to comment on the proposed format for the WallDuration and CpuDuration properties in the Usage Record - Format Recommandation.
"The lexical representation for duration is the [ISO 8601] extended format PnYn MnDTnH nMnS, where nY represents the number of years, nM the number of months, nD the number of days, 'T' is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds. The number of seconds can include up to 6 decimal digits."
If you want to convert this into seconds, or add this kind of duration to a grand total it is unclear how long a month is or a year. Is a month 30 ,31 or 28 days ? And a year is that 365 or 366 days?
The use of years and months in this representation only give rise to needless uncertainties.
Therefore I think it is better to use as duration format the number of seconds, with six decimal digits, or of you still want to use the ISO8601 standard, use it with the restriction that years and months will never be used. In that case it is always possible to convert it unambiguously to seconds.
Bart Heupers, HPC Advisor SARA, Kruislaan 415, 1098 SJ Amsterdam -- ur-wg mailing list ur-wg@ogf.org http://www.ogf.org/mailman/listinfo/ur-wg
-- ur-wg mailing list ur-wg@ogf.org http://www.ogf.org/mailman/listinfo/ur-wg
Hi all! Carl Wright wrote:
... Having said that, I can think of times when days, months and years are used in billing. In this context billing refers to the whole charges for a period of usage (day, month, ...). Rating (charging) refers to the charge for a specific event of usage/service. The situations that are day-friendly are usually in situations where you have memberships, rights, or other relationships. These come with increasing complications in the calculation of charges. You then have to have pro-ration algorithms when you have mid-period start and stops of these relationships. Just look at what happens with your wireless bills.
That's a good observation. It depends on what precision you need and what are your methods of billing/charging. I like the approach taken by the APEL developers that have, in their accounting record table (inspired by the GGF UR, but not compliant to it), columns for both an ISO8601 version of Cpu/WallDuration, as well as a version in seconds. The UR as well might have the possibility to specify both formats, such that each application/accounting system can choose on which to rely upon.
If you expect that you are charging for relatively short durations, make your life much easier by using hours, minutes and seconds.
Well, looking at some use cases we most probably can rely upon that. Above all if we are seriously thinking about some kind of aggregate usage records. Donal K. Fellows wrote:
Bart Heupers wrote:
If you want to convert this into seconds, or add this kind of duration to a grand total it is unclear how long a month is or a year. Is a month 30 ,31 or 28 days ? And a year is that 365 or 366 days?
It is a feature of that ISO spec that you can use arbitrarily large numbers for any field in durations.
That's actually what I was trying to figure out. On the ISO website I found only information on the basic ISO8601 specification that covers only date and time, time periods and durations are handled by some extension (as far as I know), but I couldn't find any exact specification (if you have some pointer I'd appreciate it). The basic ISO8601 specification wouldn't allow arbitrary numbers of days, etc. to be specified, but it does make sense for time periods.
...
The use of years and months in this representation only give rise to needless uncertainties.
Remember, you are in total control over what you produce. If you put uncertainties in, you only have yourself to blame.
Yes and no, think about interoperability between different accouning systems and maybe even Grid environments (that's exactly what we're working within the OMII-Europe project). I can make sure that I use only unambiguous specifications, maybe even only the number of seconds. But if the UR standard allows to specify also days, months and years, then I will need to be able to handle them ... the question is just: how? If I will not be able to handle them, then I will have to refuse URs coming from another systems, let's say OSG, if they handle things in a different way ... which obviously undermines all standardization efforts ... Cheers, Rosario.
Hi folks, ISO8601 allows to set the start date for a given period like in 2005-08-09T18:31:42P6M4DT12H30M17S which are 5 months, 4 days, 12hours 30 minutes and 17 seconds after 2005-08-09 18:31:42. So in principle there is no problem with using the ISO format. Personally, I prefer not to put any restriction on the ISO format. Only the timezone and hence the possible existence of daylight saving periods have to be known. E.g., in DEISA we are using UTC. Besides, ISO8601 is an official way to express date/time and time periods in the European Union (EN 28601) and Switzerland. Cheers, Thomas -- -------------------------------------------------- Dr. Thomas Soddemann | Boltzmannstrasse 2 Grid Architect | 85748 Garching Rechenzentrum der MPG | Germany am MPI fuer Plasmaphysik | --------------------------------------------------- phone: +49 89 3299 2694 | fax: +49 89 3299 1301 ---------------------------------------------------
Thomas Soddemann wrote:
ISO8601 allows to set the start date for a given period like in 2005-08-09T18:31:42P6M4DT12H30M17S which are 5 months, 4 days, 12hours 30 minutes and 17 seconds after 2005-08-09 18:31:42. So in principle there is no problem with using the ISO format.
That's not a duration, but rather a time period (which is effectively an anchored duration). Supporting that would take deep schema hacking (modifying facets of simple types IIRC) unfortunately, and what's worse, would not be well supported by tooling. Donal.
Donal K. Fellows wrote:
Thomas Soddemann wrote:
ISO8601 allows to set the start date for a given period like in 2005-08-09T18:31:42P6M4DT12H30M17S which are 5 months, 4 days, 12hours 30 minutes and 17 seconds after 2005-08-09 18:31:42. So in principle there is no problem with using the ISO format.
That's not a duration, but rather a time period (which is effectively an anchored duration). Supporting that would take deep schema hacking (modifying facets of simple types IIRC) unfortunately, and what's worse, would not be well supported by tooling.
I guess the XSD Spec is a little vague here. They state that for the element "duration" ISO8601 is applied which also allows the kind of durations you refer to as time periods, but their examples are only in the [-]P... format. Thomas -- -------------------------------------------------- Dr. Thomas Soddemann | Boltzmannstrasse 2 Projects Engineer | 85748 Garching Rechenzentrum der MPG | Germany am MPI fuer Plasmaphysik | --------------------------------------------------- phone: +49 89 3299 2694 | fax: +49 89 3299 1301 ---------------------------------------------------
Thomas Soddemann wrote:
I guess the XSD Spec is a little vague here. They state that for the element "duration" ISO8601 is applied which also allows the kind of durations you refer to as time periods, but their examples are only in the [-]P... format.
Both of these references: http://www.w3schools.com/schema/schema_dtypes_date.asp http://books.xmlschemata.org/relaxng/ch19-77073.html state that xsd:duration is to use the [-]P... format, as does the core spec at: http://www.w3.org/TR/REC-xmlschema-2/#duration It's in the first paragraph of section 3.2.6.1. Donal.
Donal K. Fellows wrote:
Thomas Soddemann wrote:
I guess the XSD Spec is a little vague here. They state that for the element "duration" ISO8601 is applied which also allows the kind of durations you refer to as time periods, but their examples are only in the [-]P... format.
Both of these references: http://www.w3schools.com/schema/schema_dtypes_date.asp http://books.xmlschemata.org/relaxng/ch19-77073.html state that xsd:duration is to use the [-]P... format, as does the core spec at: http://www.w3.org/TR/REC-xmlschema-2/#duration It's in the first paragraph of section 3.2.6.1.
Donal. -- ur-wg mailing list ur-wg@ogf.org http://www.ogf.org/mailman/listinfo/ur-wg
Yep, that's what I meant. ISO 8601 defines durations plus the optional reference date. In the spec http://www.w3.org/TR/REC-xmlschema-2/#duration it is defined that the duration is in the format of ISO8601 which would allow to specify that optional date in front of the [-]P. But a discussion on if the XSD spec is precise enough or not does not cover Bart's point. Anyway, I agree with you, that the format [-]P... allows to express a duration in a very precise way, which should cover all or at least most of the requirements of implementors. Thomas -- -------------------------------------------------- Dr. Thomas Soddemann | Boltzmannstrasse 2 Projects Engineer | 85748 Garching Rechenzentrum der MPG | Germany am MPI fuer Plasmaphysik | --------------------------------------------------- phone: +49 89 3299 2694 | fax: +49 89 3299 1301 ---------------------------------------------------
Thomas Soddemann wrote:
But a discussion on if the XSD spec is precise enough or not does not cover Bart's point.
Oh that's actually simple. He's wrong. :-) He's trying to normalize too early and it is leading him into trouble. I've learnt (the hard way) to avoid doing that sort of thing. Donal.
Hello, If you add the start date you still don't know how long it is. 2005-08-09T18:31:42P6M4DT12H30M17S How many seconds is that? In this case we could agree that 5 months after 2005-08-09 is 2006-01-09 but I have to guess that more or less. It is not specified. And which date is 1 month after 2006-01-31 or 5 months after 2005-02-28 or even worse, 12 months after 2008-2-29. Perhaps the individual records will not be that long in general, but if the processing time for a huge number of processors is taken together, then you easily add up to a number of years. Perhaps, if you want to avoid big using numbers it is also an idea to specify that in durations a month is always 30 days, a year 365 days and a day is always 24 hours. Then the ISO8601 specification is not ambiguous. But I would prefer to use seconds. Best regards, Bart Heupers, HPC Advisor 31 (0) 20 592 8071 SARA, Kruislaan 415, 1098 SJ Amsterdam -----Original Message----- From: ur-wg-bounces@ogf.org [mailto:ur-wg-bounces@ogf.org] On Behalf Of Thomas Soddemann Sent: donderdag 21 september 2006 4:14 To: Mailing List for UR-WG Subject: Re: [UR-WG] Comment on duration format for WallDuration andCpuDuration Hi folks, ISO8601 allows to set the start date for a given period like in 2005-08-09T18:31:42P6M4DT12H30M17S which are 5 months, 4 days, 12hours 30 minutes and 17 seconds after 2005-08-09 18:31:42. So in principle there is no problem with using the ISO format. Personally, I prefer not to put any restriction on the ISO format. Only the timezone and hence the possible existence of daylight saving periods have to be known. E.g., in DEISA we are using UTC. Besides, ISO8601 is an official way to express date/time and time periods in the European Union (EN 28601) and Switzerland. Cheers, Thomas -- -------------------------------------------------- Dr. Thomas Soddemann | Boltzmannstrasse 2 Grid Architect | 85748 Garching Rechenzentrum der MPG | Germany am MPI fuer Plasmaphysik | --------------------------------------------------- phone: +49 89 3299 2694 | fax: +49 89 3299 1301 --------------------------------------------------- -- ur-wg mailing list ur-wg@ogf.org http://www.ogf.org/mailman/listinfo/ur-wg
Bart Heupers wrote:
If you add the start date you still don't know how long it is. 2005-08-09T18:31:42P6M4DT12H30M17S How many seconds is that?
You are aware that that is an underspecified time? The timezone is omitted, and even with that you still would not know what DST rules to apply. And that's leaving aside the problems you've identified too. All this just goes to show that time arithmetic is hard, and best left to libraries where someone else has sorted out all the problems. [...]
Then the ISO8601 specification is not ambiguous. But I would prefer to use seconds.
It's not ambiguous. It's your "normalization" code that is wrong. :-) False normalization of values causes real trouble; it is not possible to do this correctly with durations, and because of this, if normalization is to be done, it must be done immediately before display to a real user, and not at any intermediate stage. If you want to use seconds, do so: PT<YourNumberGoesHere>S If you wish, within your Grid, to profile (i.e. restrict) the use of the usage record to require that durations are always expressed only using seconds, you can do just that. Donal.
Bart Heupers wrote:
If you want to convert this into seconds, or add this kind of duration to a grand total it is unclear how long a month is or a year. Is a month 30 ,31 or 28 days ? And a year is that 365 or 366 days?
It is a feature of that ISO spec that you can use arbitrarily large numbers for any field in durations. This is important because of precisely this issue; there is no way to automatically convert from some count of seconds to larger units. This is because, as you know, neither a year nor a month is not a fixed length. Nor are days (think daylight savings differences!) or even minutes for that matter (because of leap seconds, though they're usually glossed over). The correct thing to do in this case is to record the quantity of time units that you're actually recording in the ISO format, like this: PT12345S - 12,345 seconds PT76,25H - 76 and a quarter hours (this probably ought to be recorded in minutes though, I admit) P500DT - 500 days Don't try to "normalize" this value though; as this discussion shows, you cannot do that correctly. (Indeed, the reason why I favour the ISO 8601 duration format is that it allows the accurate capture of such granularity information.) OK, this can lead to some oddities when you add them together: P20DT100000S - 20 days and 100,000 seconds, i.e. somewhat over 21 days but that can't be helped. If you're adding amounts from the same basic accounting system (which will be the usual case I expect) then I don't expect this to be a real problem; the granularity will be the same.
The use of years and months in this representation only give rise to needless uncertainties.
Remember, you are in total control over what you produce. If you put uncertainties in, you only have yourself to blame.
Therefore I think it is better to use as duration format the number of seconds, with six decimal digits, or of you still want to use the ISO8601 standard, use it with the restriction that years and months will never be used. In that case it is always possible to convert it unambiguously to seconds.
As noted above, the ISO standard is a great deal more flexible than you believe. And your proposed requirement to use 6 decimal digits for seconds would suck; a job that ran for a fortnight (yes, they do happen in production workflows when serious amounts of data are in use) would overflow this, since a million seconds is only a bit over 11.5 days. :-) Given that a spec exists and using it (through xsd:duration) is easy, and additionally that your replacement has its own subtle set of gotchas and would also convey less information to the casual observer, I advocate going for what we have. It also means we don't need to do another spec revision. :-D Donal.
Hello Donal For the DEISA and general Grid accounting systems you just want to add amounts from different accounting systems. Of course I am in control over what I produce, but I have to interpret and use what others produce, and I don't want other systems to give the possibility to add uncertainty where it is not needed. With the 6 decimal digits for seconds I meant 6 decimal digits after the dot and a arbitrary number of digits before the dot just as this was specified in the ISO8601. Regards Bart Heupers, HPC Advisor 31 (0) 20 592 8071 SARA, Kruislaan 415, 1098 SJ Amsterdam -----Original Message----- From: ur-wg-bounces@ogf.org [mailto:ur-wg-bounces@ogf.org] On Behalf Of Donal K. Fellows Sent: donderdag 21 september 2006 10:20 To: Mailing List for UR-WG Subject: Re: [UR-WG] Comment on duration format for WallDuration andCpuDuration Bart Heupers wrote:
If you want to convert this into seconds, or add this kind of duration to a grand total it is unclear how long a month is or a year. Is a month 30 ,31 or 28 days ? And a year is that 365 or 366 days?
It is a feature of that ISO spec that you can use arbitrarily large numbers for any field in durations. This is important because of precisely this issue; there is no way to automatically convert from some count of seconds to larger units. This is because, as you know, neither a year nor a month is not a fixed length. Nor are days (think daylight savings differences!) or even minutes for that matter (because of leap seconds, though they're usually glossed over). The correct thing to do in this case is to record the quantity of time units that you're actually recording in the ISO format, like this: PT12345S - 12,345 seconds PT76,25H - 76 and a quarter hours (this probably ought to be recorded in minutes though, I admit) P500DT - 500 days Don't try to "normalize" this value though; as this discussion shows, you cannot do that correctly. (Indeed, the reason why I favour the ISO 8601 duration format is that it allows the accurate capture of such granularity information.) OK, this can lead to some oddities when you add them together: P20DT100000S - 20 days and 100,000 seconds, i.e. somewhat over 21 days but that can't be helped. If you're adding amounts from the same basic accounting system (which will be the usual case I expect) then I don't expect this to be a real problem; the granularity will be the same.
The use of years and months in this representation only give rise to needless uncertainties.
Remember, you are in total control over what you produce. If you put uncertainties in, you only have yourself to blame.
Therefore I think it is better to use as duration format the number of seconds, with six decimal digits, or of you still want to use the ISO8601 standard, use it with the restriction that years and months will never be used. In that case it is always possible to convert it unambiguously to seconds.
As noted above, the ISO standard is a great deal more flexible than you believe. And your proposed requirement to use 6 decimal digits for seconds would suck; a job that ran for a fortnight (yes, they do happen in production workflows when serious amounts of data are in use) would overflow this, since a million seconds is only a bit over 11.5 days. :-) Given that a spec exists and using it (through xsd:duration) is easy, and additionally that your replacement has its own subtle set of gotchas and would also convey less information to the casual observer, I advocate going for what we have. It also means we don't need to do another spec revision. :-D Donal. -- ur-wg mailing list ur-wg@ogf.org http://www.ogf.org/mailman/listinfo/ur-wg
Bart Heupers wrote:
Of course I am in control over what I produce, but I have to interpret and use what others produce, and I don't want other systems to give the possibility to add uncertainty where it is not needed.
But you're the one adding uncertainty by trying to convert everything into seconds. If you stop doing that, the uncertainty goes away. If people are accounting for stuff in months (I've no idea why they would) then it is false accuracy to pretend that it anything else.
With the 6 decimal digits for seconds I meant 6 decimal digits after the dot and a arbitrary number of digits before the dot just as this was specified in the ISO8601.
Oh, the fractional part. I see no point in specifying how precise that should be in the standard; there are too many nasties lurking. Donal.
Donal K. Fellows wrote:
Bart Heupers wrote:
Of course I am in control over what I produce, but I have to interpret and use what others produce, and I don't want other systems to give the possibility to add uncertainty where it is not needed.
But you're the one adding uncertainty by trying to convert everything into seconds. If you stop doing that, the uncertainty goes away. If people are accounting for stuff in months (I've no idea why they would) then it is false accuracy to pretend that it anything else.
Then what about aggregation? How would you compute the total CPU time "consumed" by a user within the last year if some of the records contain only seconds while others use also days and months. In this use case you have to convert somehow. Of course, you might have something like P123DT1686255S ... but give that value to the management board of the LCG and let's see what they'll tell you ... :o) Let's face it, we can't get easily around ambiguity with ISO8601 periods. Again, I don't say we shouldn't use them, but we need to be aware that there will always be use cases where they will be ambiguous. Cheers, Rosario.
Rosario Michael Piro wrote:
Then what about aggregation? How would you compute the total CPU time "consumed" by a user within the last year if some of the records contain only seconds while others use also days and months. In this use case you have to convert somehow. Of course, you might have something like P123DT1686255S ... but give that value to the management board of the LCG and let's see what they'll tell you ... :o)
Let's face it, we can't get easily around ambiguity with ISO8601 periods. Again, I don't say we shouldn't use them, but we need to be aware that there will always be use cases where they will be ambiguous.
We can precisely represent the ambiguity if necessary. If one site is genuinely measuring chargable time in months, you're in trouble anyway as mixing months and seconds is hard. If you squelch the problem in one place (e.g. by forcing everything to be recorded in seconds) you just end up with it popping up elsewhere (e.g. sites producing records with inaccurate/incorrect durations). Since there is no perfect solution, we'll go with xsd:duration as that is good for other reasons (i.e. people will interpret it correctly when they read the schema, and nobody is precluded from recording what they want). The other advantage of this is that it means we get URv1 to the GGF Editor sooner rather than later... :-) Donal.
Folks: Please remember that all this measuring and processing of measurements is about the allocation of resources and of money. What is the cost to you and your partners of ambiguity in measurement? How hard will it be to move to new processes using this data? You'll certainly see new applications for processing this information. Will research not get done because of disagreements over the allocation of this money (cost)? What decisions can we make that will make it easier for people to cooperate and get the work we support done? Carl A. Wright Service Level Corporation +1 734-827-2000 ext. 219 (voice) +1 734-827-2200 (fax) http://www.servicelevel.net/ PS: I think standards are useful, but I was disturbed by comments that treated standards as though they were gold-plated. The fact that an ISO or EU standard exists matters little if it doesn't serve our goals. Those standards were made by mere mortals like ourselves with their independent goals that they were striving for. I'm not arguing against using them, just use them with our goals in mind.
Bart Heupers wrote:
Hello Donal
For the DEISA and general Grid accounting systems you just want to add amounts from different accounting systems.
Of course I am in control over what I produce, but I have to interpret and use what others produce, and I don't want other systems to give the possibility to add uncertainty where it is not needed.
Exactly what I have to worry about in the OMII-Europe project on interoperability. I will HAVE to accept ambiguos values if they can be legally specified within an UR, I just don't know how I can handle them, but I have to, otherwise I'll throw overboard all standardization efforts if some third party sends me a perfectly correct UR (according to the specs) that contains a time period of let's say P11M13D2HTsomething ... I cannot refuse to handle this record if I want to be compliant to the UR spec (and I need to be), but I can just guess what the producer might have meant. I will not get around ambiguity if the UR spec allows such values. Note: I do not say that I want these values to be restricted, but we need to be aware that it's not enough to say that someone can internally use unambiguous versions. It is not enough, unfortunately. Cheers, Rosario.
participants (6)
-
Bart Heupers -
Carl Wright -
Donal K. Fellows -
Laura F McGinnis -
Rosario Michael Piro -
Thomas Soddemann