Re: [humanmarkup-comment] HumanML Schema Discussion Topics

[Rex Brooks <rexb@starbourne.com>]

Title: Re: [humanmarkup-comment] HumanML Schema Discussion To

I sent it to both lists, so it will be duplicated now. At least it is more likely to get some attention, eh? In any event, it is a topic for discussion and for the agenda of the TC meeting, both.

Please understand that what I'm calling for is requirements from applications areas, i.e. what they need from us for our work to be useable. And I'm concentating on our subcommittees in particular. That is about as "living" a set of examples as we can get, don't you think? The people who are actually going to use it? I toccurred to me as I was reviewing the Web Services stuff that we have the horse behind the cart here, and we need to reverse that fast. Nobody will use what we do if we don't make it so that they can. They are not going to follow us, so we better get used to following them.

That happens before we start work on this first working draft of the Schema.

 I'll defer the namespace discussion for now. I looked it up in our documents and it seemed to me after reviewing the spec sample that we needed to use the prefix name as the first part of the record .xsd schema file. I remember the discussion as being that HumanML was the name by which we would refer to the language and that is also in our HMI.basicinfo file. It's not important right now, so we can take it up later in an effort to be certain we are correct.

Processing requirements is no more abstract that saying we want to be able to count the number of times a certain HumanML tag is used in a group of documents. It can be more abstract, but again, we are asking for the information from the people who will be wanting to use it, so it is going to have to be as abstract as THEY, not us, make it.

Ciao,

Rex

At 3:56 PM -0500 12/15/01, Ranjeeth Kumar Thunga wrote:

> Thanks for this summary.  I am sending it only to
> the comments list (since I believe everyone in the TC is also a member
> of the comments lists as well.)
>  
> 1)
> It is
> difficult to develop a schema on its own, in an abstract fashion,
> without living examples, which I believe Len had
> mentioned.   The last example I remember was from Joe,
> who had a fictional story to markup with HumanML, to
> showcase the technology.   Non-HM life priorities hit many
> of us simultaneously, but to let you guys know, I have been working on
> an elaborate diplomatic communications scenario as well. 
> I will post it up when I can dedicate sufficient time to
> follow up on it (which still may not be for a few
> weeks.) 
>  
> 2)
> Or
> schema is best called humanml.xsd (not huml.xsd)...going
> back to our earlier debates.
>  
> 3)
> Outlining
> "Processing Requirements" are too abstract for me right now,
> and calls back to the controversy regarding having a class diagram as
> part of our effort (i.e. are we designing an application, or are we
> designing a data model?)...it is useful to further elaborate
> on Processing Requirements, so that we can provide API's for
> others to tap into HumanML.  However, after we lay out a few more
> scenarios, it will be easier to conceptualize what these would be
> (that's what I think, at least...you guys are welcome to prove me
> wrong).
>  
> That's all
> for now.  Thanks again Rex for bringing these issues up to
> date.
>  
>  
> Ranjeeth
> Kumar Thunga
>  
> > ----- Original Message -----
> > From: Rex
> > Brooks
> > To: humanmarkup@lists.oasis-open.org ; humanmarkup-comment@lists.oasis-open.org
> > Sent: Saturday, December 15, 2001 12:25
> > PM
> > Subject: [humanmarkup-comment] HumanML Schema
> > Discussion Topics
> >
> > Hi Everyone,
> >
> > As of 12/19/01, our
> > next TC meeting, we have made little progress on the basic work
> > product of the Human Markup Language, our Basic XML Schema, during
> > Phase 1. This is a statement of fact and is intended only to assess
> > the current situation in preparation for some suggestions I would like
> > to put forward for proceeding with this effort.
> > We have asked Len Bullard to head this part of the HumanMarkup effort
> > as our Invited Expert, but we have given him no assistance and no
> > guidance, nor have we asked for a formal plan to move forward with
> > developing the Human Markup Language Schema or Schemata. So it is
> > neither surprising that little work could be done on this main work
> > product, nor entirely unanticipated.
> >
> > A bit of recent history will be helpful to this disucssion.
> >
> > With our first TC meeting scheduled for Sept. 17, 2001, our work, like
> > that of most of the world has been effected by the events of Sept. 11,
> > 2001. The second TC meeting on Oct. 17, 2001 coincided with the
> > Universal Access, Collaboration Expedition Workshop #7, October 16,
> > 2001 organized and conducted by Susan Turnbull of the GSA, at which
> > Ranjeeth was invited to speak about the HumanMarkup effort, and his
> > subsequent visit the following day to the Emerging Technologies Task
> > Group Committee meeting of the xml.gov working group to which he was
> > invited by Owen Ambur, co-chair of that working group. So, while we
> > accomplished the basic set up of the TC in September and the first two
> > subcommittees, and we revised our calendar for deliverables in
> > October, formulating a more complete work plan was not
> > possible.
> > A number of factors
> > prompted us to postpone and then cancel the November TC
> > meeting
> >
> > However, we are on
> > track to complete the first working drafts of our core documents by
> > Dec. 31. We have two subcommittees in place and a third ready to be
> > pursued. We have made valuable contacts in Washington, D.C. We are
> > gathering requirements from a few of the fields for which we intend to
> > provide Human Markup Language as an HLAL for applications which can
> > achieve some part of our charter. So we are making some progress,
> > albeit more slowly than we had wished.
> > While this particular message is not intended to be a complete
> > year-end evaluation, I thought some assessment of the current
> > situation was in order as background for what I want to suggest as a
> > work plan.
> >
> > Following Len's initial development of an xml toolkit schema, I think
> > that we should produce a basic Phase 1 document: huml.xsd
> >
> > This will be the first document to fill the namespace allotted for us
> > by OASIS. I believe we can say as an official comment in this base
> > schema, to use an adaptation of Len's first draft statement:
> >
> > "For this base schema (Len used the term appropriate for his
> > phase 0 document: first draft), all the schema types are in one
> > schema for the ease of reference (Len used the term:
> > production). Later, these will be broken into modules, or
> > particular schemata (my terms) for better reuse in other
> > languages."
> >
> > I think that we should take Len's first schema toolkit and make what
> > amendments we decide are needed in light of what we learn from a
> > rigorous, formal evaluation of the requirements from the application
> > areas we wish the Human Markup Language to serve. This is what we are
> > in essence, doing anyway, but I want to formalize it.
> >
> > This is separate from the Language Specification Requirements
> > enumerated in HM.requirements from our core documents, which defines
> > working terms for complete compatibility with W3C XML
> > conventions.
> > I think we need to
> > specify milestone dates for these requirements to be submitted by the
> > subcommittees we have formed, or will form before the milestone dates,
> > and any parties whose interests need to be served by the Human Markup
> > Language, and who can submit those requirements by the milestone
> > dates. I think we need to make this invitation-for-submission
> > milestone date for collecting requirements public in a way that
> > reaches the widest and most closely HumanMarkup-related audience
> > possible. This should be done after the first of the year to avoid
> > being lost in the barrage of public service advertising during the
> > end-of-year holiday season. Since we don't really have the time to do
> > it before then, this is really rather self-fulfilling, but, hey, we
> > can say we followed our own advice, eh?
> > Once we have the requirements, we should ask Len to begin work with a
> > team of volunteers that he approves according to a timetable he
> > presents upon evaluating the requirements.
> > Further I think that all or most requirements submissions should be
> > broken down into two categories, as I also think the  basic XML
> > Schema ought to be:
> >
> > 1-Processing Requirements: How language operators should work. What
> > functions are required. How is the data to be manipulated.
> >
> > 2-State Description Requirements: How language should model data for
> > human mental, psychological, cultural, or other contextual states or
> > conditions or preconditions for required elements and attributes and
> > how should these be broken down in simpleTypes and complexTypes.
> >
> > The purpose of the basic huml.xsd is to give us a basic namespace
> > reference which can then be expanded upon in modular
> > fashion.
> >
> > Ciao,
> > Rex
> >
> > --
> > Rex
> > Brooks
> > GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
> > W3Address: http://www.starbourne.com
> > Email: rexb@starbourne.com
> > Tel:
> > 510-849-2309
> > Fax: By
> > Request

-- 

Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com

Tel: 510-849-2309

Fax: By Request