DateTimeTypes

[andreb1972]

Is there a reason why DateTime data sometimes uses a core DateTimeType, and in other cases uses a specialized type like PublishedDateType, ApprovalDateType etc.

From what I can see in the definitions of the specialized Types, they just restrict to the Core DateTimeType. The approach is inconsistently used. I assume this is a legacy issue, but we should stick to one approach or the other - either make everything a DateTimeType, or make some rules for the specialized types and apply them across the schemas.

[Dennis-Brandl]

For the first pass I just used DateTime type. In hopes that we would raise this question.

Is there any value in using a specific type when it is not used as a key into another schema?

Looking for answers or recommendations.

Dennis

Dennis Brandl

208 Townsend Ct, Suite 200

Cary, NC 27518-8319, USA

+1-919-852-5322 (Office)

+1-919-656-2205 (Cell)

+1-832-201-0554 (Fax)

http://www.brlconsulting.com/ www.brlconsulting.com

<mailto:DnBrandl@BRLConsulting.com> DnBrandl@BRLConsulting.com 

From: andreb1972 [mailto:notifications@github.com] Sent: Monday, February 4, 2019 7:40 PM To: MESAInternational/B2MML-BatchML B2MML-BatchML@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [MESAInternational/B2MML-BatchML] DateTimeTypes (#26)

Is there a reason why DateTime data sometimes uses a core DateTimeType, and in other cases uses a specialized type like PublishedDateType, ApprovalDateType etc.

From what I can see in the definitions of the specialized Types, they just restrict to the Core DateTimeType. The approach is inconsistently used. I assume this is a legacy issue, but we should stick to one approach or the other - either make everything a DateTimeType, or make some rules for the specialized types and apply them across the schemas.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MESAInternational/B2MML-BatchML/issues/26 , or mute the thread https://github.com/notifications/unsubscribe-auth/AQKLgrJA2h6tZXFFWDKCkO6rehOVsFeKks5vKNLJgaJpZM4aiUyg . https://github.com/notifications/beacon/AQKLgvG-QEjuvhNZZgNv6BOGPm4RPhs4ks5vKNLJgaJpZM4aiUyg.gif

[andreb1972]

I've used both approaches with our internal schema's, but always consistently across each namespace. Originally I did specializations of all types, but found that this was creating extra work for no reason. Now I use a core type, unless there is a specific rule I want the developer to consider. The rule is usually in documentation, although for some types they can be enforced in the XSD.

[Dennis-Brandl]

Maybe it's time to remove most of the intermediate types,and just indicate the semantic rules in the documentation, since the rules are not really enforced. This means all of the DateTime derived times move to just DateTime, and others move to the UNCE/FACT types.

[BrentHumphreys]

Maybe it's time to remove most of the intermediate types,and just indicate the semantic rules in the documentation, since the rules are not really enforced. This means all of the DateTime derived times move to just DateTime, and others move to the UNCE/FACT types.

I agree with this.

[Dennis-Brandl]

At the February 11, 2019 meeting we decided to remove the intermediate types. We will generate a branch and then submit as a pull request.

[Dennis-Brandl]

All date and time intermediate times to be removed in the January 2020 Sprint.

[JoeDo]

All date and times fields appear to reference the core DateTimeType in the January-2020-Sprint branch. I'll circle back and Close this issue after the changes have been merged into Master.

[Dennis-Brandl]

Merging soon. Will close this issue.