[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [obix] Groups - oBIXfigure1UML.png uploaded (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: FOUO Yes, I think that's a wise idea. We should at least vet it through our Thursday committee meeting if we can allot 10 mins for it. -chris -----Original Message----- From: Gemmill, Craig [mailto:craig.gemmill@tridium.com] Sent: Wednesday, May 08, 2013 1:01 PM To: Bogen, Chris ERDC-RDE-ITL-MS; obix@lists.oasis-open.org Subject: RE: [obix] Groups - oBIXfigure1UML.png uploaded (UNCLASSIFIED) Good point - it really isn't an obix:str. I think I see what you're saying then. I'm not sure what the best answer is yet. Maybe xs:string is right. If it's ok, I'll hold off on including the UML pic until we discuss and digest a little more. -----Original Message----- From: Bogen, Chris ERDC-RDE-ITL-MS [mailto:Chris.Bogen@erdc.dren.mil] Sent: Wednesday, May 08, 2013 1:18 PM To: Gemmill, Craig; obix@lists.oasis-open.org Subject: RE: [obix] Groups - oBIXfigure1UML.png uploaded (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: FOUO We could say obix:string, but I think in a couple of cases we would end up with a collision on naming the native type and the oBIX class. I am open to the idea of not using the "xs" namespace if it introduces unwanted binding to xml - though in the spec, we are still saying that the native type must conform to the xsd namespace. I would want to put them in a different namespace than just "obix" though to avoid confusion. "native:string" or "obix.native: string" would be acceptable if we provided a note that specified that the target native types must conform to the xsd type restrictions. In any case, I think it's important that we distinguish because 'name' is not an obix:str. An obix:str is a class that inherits from obix:val and obix:obj. In the case of 'name' we are only asking for a literal string value, not inclusion of an obix:str object. I was actually confused about that looking at Figure 1 before I modified it. I don't necessarily want to go crazy with the UML modeling (adding sterotypes, etc), but it is good to be as precise as possible. It's far too late to change this, but I also think the abbreviated style of the oBIX class names are bad style - though they could decrease your data payload quite a lot. For example, why have 'err' when 'error' is only two more characters? Same goes for other types like 'str,' 'obj' etc. Regards chris -----Original Message----- From: Gemmill, Craig [mailto:craig.gemmill@tridium.com] Sent: Wednesday, May 08, 2013 11:51 AM To: Bogen, Chris ERDC-RDE-ITL-MS; obix@lists.oasis-open.org Subject: RE: [obix] Groups - oBIXfigure1UML.png uploaded One thing I would rather see is these things defined in terms of their oBIX constructs, instead of the xsd types. Maybe this is what 1) is about, but it would seem more self consistent if, for example, the 'name' attribute were an obix:str, instead of an xs:string. Even though obix:str maps to an xs:string, the name is really an obix:str and the fact that the two are the same is sort of a coincidence of the way we defined obix:str. Is it somehow invalid UML to have it be an obix:str instead of xs:string? I'm not an expert at UML. I can easily embed this into the doc once we agree on whether this is ok. From: obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org] On Behalf Of Chris Bogen Sent: Tuesday, May 07, 2013 4:02 PM To: obix@lists.oasis-open.org Subject: [obix] Groups - oBIXfigure1UML.png uploaded Submitter's message I uploaded a draft version of a new Figure 1 for the next working draft. I can arrange it to look better in the final version, but wanted to get feedback first. My goal was to represent the object model in UML class diagram notation, but with a little more detail. As it currently exists Figure 1 is technically a very simple UML class diagram. Major changes: 1) I added namespace/package prefixes to distinguish between oBIX and native or xsd mapped types. As it is the diagram is ambiguous. 2) Represented "val" as a proper parameterized class with type binding relations from subclasses. 3) Added the "status" enumeration for clarification. There are some issues that I found while making the diagram, such as... a) why does int use a uri for units while date uses a string? b) In facets there is discussion about using tz in abstime, date, or time, but in the current Figure 1, tz is not an attribute of those classes. c) related to b, why doesn't reltime have units? Regards, Chris -- Chris Bogen Document Name: oBIXfigure1UML.png <https://www.oasis-open.org/apps/org/workgroup/obix/document.php?document_id=49102> ________________________________ Description A draft revision of the oBIX Figure 1 illustration Download Latest Revision <https://www.oasis-open.org/apps/org/workgroup/obix/download.php/49102/latest/oBIXfigure1UML.png> Public Download Link <https://www.oasis-open.org/committees/document.php?document_id=49102&wg_abbrev=obix> ________________________________ Submitter: Chris Bogen Group: OASIS Open Building Information Exchange (oBIX) TC Folder: Contributions Date submitted: 2013-05-07 13:01:51 Classification: UNCLASSIFIED Caveats: FOUO Classification: UNCLASSIFIED Caveats: FOUO
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]