<div dir="ltr"><div><div><div><div>I want to repeat a suggestion that I made earlier. even though I know<br></div>that it was pooh-poohed by Gerard. But I still think it could ameliorate<br></div>teh concerns and it did not really receive serious consideration.<br><br></div>Right now (i.e., before the message Mark just posted) we have the<br>following options for attribute multiplicity:<br></div>n<br><div>0,n<br></div><div>where n is a positive integer.<br></div><div>Mark's message would also allow:<br></div><div>0..n<br>0..*<br></div><div>What I had suggested is to restrict this somewhat by requiring that<br></div><div>any indeterminate (that is, in the model) attribute multiplicity be<br></div><div>explicitly stated through a non-negative attribute, replacing <br></div><div>0..n and 0..* simply by:<br></div><div>n<br></div><div>as is currently allowed, but with n being either a literal or a non-negative integer attribute, like<br></div><div>n:nonnegativeInteger<br></div><div>a:real{multiplicity=n}<br><br></div><div>So, the question is: would this help in preventing bad modeling?<br></div><div>I thought it might, since it makes the model less indeterminate.<br></div><div><br></div><div>Cheers,<br><br></div><div> - Arnold<br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">-------------------------------------------------------------------------------------------------------------<br>Arnold H. Rots Chandra X-ray Science Center<br>Smithsonian Astrophysical Observatory tel: +1 617 496 7701<br>60 Garden Street, MS 67 fax: +1 617 495 7356<br>Cambridge, MA 02138 <a href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a><br>USA <a href="http://hea-www.harvard.edu/~arots/" target="_blank">http://hea-www.harvard.edu/~arots/</a><br>--------------------------------------------------------------------------------------------------------------<br><br></div></div></div>
<br><div class="gmail_quote">On Fri, Feb 19, 2016 at 3:47 PM, CresitelloDittmar, Mark <span dir="ltr"><<a href="mailto:mdittmar@cfa.harvard.edu" target="_blank">mdittmar@cfa.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>All,<br></div><br></div>Update on this topic:<br></div> In a recent focus-meeting in Baltimore, this topic was heavily discussed and explored.<br><br><br></div>The primary reason for the restriction is that it typically will catch an instance of 'bad' modeling,<br></div><div>where a concept has been denormalized to a simple type. It is not that there is something <br></div><div>inherently wrong about the open multiplicity. It was also noted, that the same 'bad' modeling<br></div><div>is not caught when the multiplicity is a fixed length.<br></div><div><br></div><div>However, there seems to be areas where it MAY be useful to have such multiplicity.<br></div><div>In reviewing the concequences of needing to allow this condition later, it seems that <br></div><div>it may be large.. effecting vo-dml spec, and possibly votable spec as well. <br></div><div><br></div><div>In the end, it was agreed that vo-dml should be modified to allow the open multiplicity on attribute types. <br></div><div>It was agreed that the document should be be very clear about the modeling concern and that the <br></div><div>condition should be strongly discouraged. As a procedural matter, occurances should be discussed <br></div><div>within the group for alternative representations.<br></div><div><br></div><div>Actions:<br></div><div> GL - update the specification accordingly.<br></div><div> update xslt scripts to issue WARNING when the condition is detected as a reminder to <br></div><div> review the modeling.<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><div><div><br></div><div>Mark<br><br></div></div></div></font></span></div>
</blockquote></div><br></div>