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] Updating our progress and the TC process to date

Title: Updating our progress and the TC process to date
Hi Everyone,

Sorry for the mini-barrage but we have a lot on our plates, in case you didn't notice.

Friday's exchange with Len over the Base Schema Element 'thought' has focused a problem that is very appropriate to the fact that this is the last of the single, atomistic elements from the first draft or straw-man schema toolkit Len provided for us in Phase 0.

I refer you to my separate post this morning on that in the "Base Schema - thought" thread.

We still have the Global Attributes to discuss for our first pass through the specification and then our final review including the new elements we have added in the course of this process.

Hopefully we also field proposals for when and how to conduct the work of creating both the adjunct Len mentioned to model specific processes for using our elements as input and output, and the semiotic processor which he and Sylvia have been exploring.

I also want to commend Manos, not only for working on the RDF Schema to connect our elements to definitional resources and to standards for measurements, but also for volunteering to investigate the proposed User Interface Markup Language (UIML) TC. Thanks Manos, if that group takes off, we will have yet another TC with which we must interoperate.

I think we need to give a bit of thought to adding additional spectra or scales besides decimal 0-1, but that is for another message.

Wrapping this up by Oct. 31, 2002 will be a challenge, but I think we can do it if we put the necessary effort into the last laps here.

Since I quite recently formatted our Working Draft Requirements Document in the OASIS-approved plain-HTML with Cascading Style Sheets and in Microsoft Word (which I have not yet added to the website as of 10-12-02) and which I will also format in XML which uses XSL with FO, which if you are not familiar with the intricacies of the XML standards family stands for Extensible StyleSheets Language Formatting Objects. I mention all this as a preamble to this message because I will shortly be casting our first OASIS TC Specification in these formats, as well as in the .xsd file which will define all the elements in our Primary Base Schema and be the first document of record in our huml namespace, once it passes through the OASIS process.

You will note that I am making a fairly bold assumption that this first draft will proceed through our own TC process to become a TC specification recommendation. I may well be assuming wrongly in that since we do have a few sticking points to iron out, particularly with regard to an additional set of Global Attributes and a method or means for adding elements as needed in the future.

So the issue of 'thought' versus 'thought process' is apt for this wider discussion, as well as for the atomistic element 'thought' on its own merits, or liabilities.

First, to summarize, it appears that Len and I agree that 'thought' as a poorly defined set of thought types, which is probably the best we could come up with if we were to just bear down on arriving at some consensus now, should not be in this version of the Primary Base Schema. I just phrased this specification as a "version" because that is the most universal process for amending or changing specifications today, and I did that to bring that discussion into this process.

So, while I think we should adopt the practice of assigning version numbers mostly for the sake of appearances, I don't think we want to establish one simple all-encompassing versioning process as it is currently practiced. Neither do I think we should court criticism for diverging too much from accepted and understood practices.

What I mean is that I do not think it would work for us to conduct full-scale, specification-wide revisions to add single or even groups of elements as the need is made clear by application-area specific recommendations or offerings of candidate elements. It should be, in my opinion, a narrowly-focused procedure that considers only the specific elements on the basis of the merit or purpose proposed for the elements. So what I would propose would be an element-by-element process, with an exception for related groups (such as an atomistic element in the Primary Base Schema with an associated and derived set of elements in the Secondary Base Schema) with perhaps another exception for a set of Primaries each with its own Secondaries. (This corresponds to Primitives and Extended Primitives.) However, I think that we can take that up later and I would suggest that this process ought to be part of a finalized draft of the Requirements Document where we can add specific clauses to the Sections to which this process applies, such as Compatibility, Modularity and Extensibility, where we stipulate these considerations.

So how's that for equivocating for the sake of finishing up the Primary Base Schema in the timeline at which we have aimed?

And while I am confessing to rationalizing a selfish goal, let me also say that I have a great need to get out our specification now so as to stagger our work ahead of my Web Services work because the latter is much more complicated and time consuming in terms of two-hour weekly working meetings and quarterly (although this first year will have seen five (5) face-to-face meetings of which I will have only attended three (3)--as opposed to HumanMarkup's monthly meetings. When both (Now three TCs since I signed onto the WSRP TC to synch webmastering for WSIA) approach target dates for deliverables in tandem, it is very taxing, and my performance suffers.

So that about sets the record straight in term of updating the progress of our work.

I will definitely be sending out an agenda for Wednesday's meeting because we just have too much to discuss and do for it to be a more wide-ranging and free form discussion, as we all prefer.

I thought it wise to bring everyone up to date now because I have been tossing out quite a lot of related standards progress reports lately, and while this is not everything, since it leaves out significant developments in the Web 3D Consortium which affect the intersection of HumanMarkup and WebServices and 3D, but this is about as much as I think it wise to ask you all to absorb.

The genda will be come out with the next reminder of the telecon Wednesday.

Have a nice weekend,
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