OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup message

[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, cognite@zianet.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" <rexb@starbourne.com>
>>>To: <humanmarkup@lists.oasis-open.org>; <cognite@zianet.com>;
>>><clbullar@ingr.com>; <kurt@kurtcagle.net>; <mbatsis@netsmart.gr>
>>>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 * rexb@starbourne.com
>>>>
>>>>
>>
>>
>>--
>>Rex Brooks
>>Starbourne Communications Design
>>1361-A Addison, Berkeley, CA 94702 *510-849-2309
>>http://www.starbourne.com * rexb@starbourne.com
>>
>>
>>


-- 
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC