[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [humanmarkup] Re: New attributeGroup:humlTemporalAtts?
I think we should hold onto that idea for the public comment period--there are a few other considerations that will need to be worked through and this could be a productive part of those discussions. As much as it tasks me, I am pretty sure we will be doing this again, and I am not sure what is the best way to go about it. I would truly prefer to not rework the whole thing again, but it may be necessary. We need to be consistent in our naming conventions, so as a third global attributeGroup, this term will need the Atts as in humlIndentifierAtts and humlCommAtts, but I have a feeling that we will have quite a bit of Temporal terminology finding its way into the html, pdf and Word versions of the spec, and it might be better to be consistent, but I can't say for sure yet. I ran across some research I will be able to judge better tomorrow--in relation to your previous concept of a Geo-Temporal attribute. Also, it gets to be difficult in these here woods to remember that we are setting the stage for the enumeration of complexType elements and sequential simpleType attributes in the Secondary Base Schema. I suspect that the Secondary is where the iterative recurrence cases might be dealt with better. (I sorta gave out while pondering chronemic today just after I found the research I just mentioned--see my second post on PBS-Doc-chronemic .) And, as if that wasn't enough of a new wrinkle, it turns out that there are also some internal structural issues that probably won't reveal themselves until we can look at the Primary Base Schema as a whole. And, of course, it turns out that we're joining in the pioneering of some namespace management issues I will address with my final presentation to our voting group. That was pretty much unintentional, but I now have the cooperation of both HR-XML Consortium and XNSORG, so there is a very good set of reasons for following through with importing namespaces. All in all a productive day, but tiring. I haven't given up on finishing the first draft Thursday, but it is going to be a stretch. Ciao, Rex At 8:31 PM -0600 10/22/02, email@example.com wrote: >To cover periodic (iterative recurrence cases), perhaps this could >be repeatable >(Kleene-star style). There are many grammatical cases as well as >physical-world ones to cover. It really gets into temporal logics, where I >believe after something over a decade of implementing they've gone from just >point dateTime to intervallic duration combined with points. The from- to- >might just work. How about a shorter moniker, say > >humlWhen > >SC > >At 12:38 PM 22-10-2002 -0700, you wrote: >>You convinced me. Thanks >> >>Ciao, >>Rex >> >>At 11:39 AM -0700 10/22/02, Kurt Cagle wrote: >>>Why not just use an xs:dateTime type here, rather than having separate >>>fields for date and time? >>> >>><xs:attribute name="fromDate" type="xs:dateTime" use="required"> >>><xs:attribute name="toDate" type="xs:dateTime" use="required"> >>> >>>You need to include the time element anyway because of the use="required" >>>and its easy enough to parse off the time if you don't need it (it also cuts >>>down on the number of attributes). If you don't know the time, you can also >>>always just assume midnight: T00:00:00.000Z >>> >>>Sorry to add this note now to your overburdened workload, but it just makes >>>more sense to me to do it this way. >>> >>>-- Kurt >>> >>>----- Original Message ----- >>>From: "Rex Brooks" <firstname.lastname@example.org> >>>To: <email@example.com>; <firstname.lastname@example.org>; >>><email@example.com>; <firstname.lastname@example.org>; <email@example.com> >>>Sent: Tuesday, October 22, 2002 11:13 AM >>>Subject: New attributeGroup:humlTemporalAtts? >>> >>> >>>> Hi Everyone, >>>> >>>> First, I really, really hate this. I truly do not want to extend the >>>> public-comment discussions, but I keep running into this problem with >>>> date and time ranges in our elements. It seems unavoidable to me that > >>> we need to specify a standard way make these designations. And, >>>> because we have not discussed on the public lists, and it is NEW, and >>>> not just a refinement of something we have discussed, I want to get a >>>> group assessment of whether I should post this to the public comment >>>> list and rish confusing issues? >>>> >>>> This is what seems like the wisest thing to me: >>>> >>>> <xs:attributeGroup name="humlTemporalAtts"> >>>> <xs:annotation> >>>> <xs:dcoumentation xml:lang="en"> >>>> <xhtml:h2>Human Temporal Attributes<?xhtml:h2> >>>> <xhtml:p>This is used to designate time and >>>> date periods using the standard representations in the format of from >>>> a date and/or time to a later date and/or time.</xhtml:p> >>>> </xs:documentation> >>>> </xs:annotation> >>>> <xs:attribute name="id" type="xs:ID" use="required"> >>>> <xs:attribute name="humlName" type="xs:string" use="required"> >>>> <xs:attribute name="fromDate" type="xs:date" use="required"> >>>> <xs:attribute name="toDate" type="xs:date" use="required"> >>>> <xs:attribute name="fromTime" type="xs:time" use="required"> >>>> <xs:attribute name="toTime" type="xs:time" use="required"> >>>> </xs:attributeGroup> >>>> >>>> Gosh, I hope this is the last exception. I will have some interesting >>>> tales to tell when this is done. Insistence on consistency might be >>>> the bugaboo of small minds, and if so, my mind is getting smaller all >>>> the time. >>>> >>>> Please let me know what you think. >>>> >>>> Ciao. >>>> Rex >>>> -- >>>> Rex Brooks >>>> Starbourne Communications Design >>>> 1361-A Addison, Berkeley, CA 94702 *510-849-2309 >>>> http://www.starbourne.com * firstname.lastname@example.org >>>> >>>> >> >> >>-- >>Rex Brooks >>Starbourne Communications Design >>1361-A Addison, Berkeley, CA 94702 *510-849-2309 >>http://www.starbourne.com * email@example.com >> >> >> -- Rex Brooks Starbourne Communications Design 1361-A Addison, Berkeley, CA 94702 *510-849-2309 http://www.starbourne.com * firstname.lastname@example.org
Powered by eList eXpress LLC