[chairs] Re: Questions and assistance with Kavi

[Karl Best <karl.best@oasis-open.org>]

Luc:

Wow, a lot of questions.

> We have a few questions that we'd like answers to:
> 
>      o How do you add quick links such as those listed on the main
>   page (e.g. charters and chairs)? We would like to add links
>   pointing to specific TC processes for example such as that
>   posted at
>   http://oasis-open.org/committees/uddi-spec/#charter. If this
>   is not to be done on the main page, where do we direct the
>   public/TC membership to this type of information? Should we
>   use the ?Public Description? of the TC to do this for the>   purpose of the public and repeat this info for the purpose
>   of the TC?

I'm going to take care of pointing to the charter. The note that I sent 
out to the chairs list on Friday explained this.

> o How can we upload html docs that contain embedded content
>   held that is in a sub-folder? There are a couple of issues
>   as its stands: 1) no subfolder support and 2) we can't hide
>   subfolders from being listed. Re 2), the ability of hiding
>   subfolders would allow the public to focus on the document
>   rather than its associated data contained in the ?content>   http://oasis-open.org/committees/uddi-spec/doc/bp/ for
>   example of display problems introduced by having a mix of
>   html files and related content displayed in one location)
 > o There is a need for support multi-level subfolders. UDDI
 >   Spec TC uses it extensively e.g.
 >   http://oasis-open.org/committees/uddi-spec/doc/source/.
 >   How/when can we get this functionality exposed?

I believe that there is subfolder capabaility for the document 
repository. Chris: please correct me if I'm wrong.

> o We need a way to bulk load content (e.g. an html doc may
>   have 10's of related gif files - see
>   http://oasis-open.org/committees/uddi-spec/doc/source/v3/website-dist/uddi_v3.htm
>   for example where
>   http://oasis-open.org/committees/uddi-spec/doc/source/v3/website-dist/UDDI_v3_files/
>   contains the embedded content). What is available to perform
>   bulk upload and updates?

Kavi is working on a bulk import utility for us right now. I'll send out 
more information once this is available. Essentially we'll just grab 
everything that's in your TC's directory (except the home page) then 
provide you with a list of files that were grabbed so that you can give 
the metadata for the files.

> o We need an area where we can store source files that are
>   available only to the TC (i.e. hidden from the public) to
>   hold work-in-progress drafts, source files for posted html
>   doc content. As such, we would like the ability to hide
>   folders; hiding documents does not suffice.

I know that individual files can be marked as non-shared (so visible 
only to the TC members); I'm not sure if entire folders can be so 
marked. Chris: can you answer this?

>  As a general comment, as it stands, we seem to have lost the
>  ability to provide some of the info we currently hold today on our
>  respective web pages. Could you explain how TCs can informally
>  expose the following:
> o where we list (subject matter related) mailing lists?
> o where we post a synopsis of TC specs (e.g.
>   http://oasis-open.org/committees/uddi-spec/#documents)
>   providing descriptive and contextual info about the specs?
>   Use of folders will not suffice.
> o where we post info about meetings that is static in nature
>   e.g. how often, meeting time by location e.g.
>   http://oasis-open.org/committees/uddi-spec/#schedule?
> o where we post our minutes?
> o where we post press-related matter?

We'll have a link to subscription info and mail list archives from your 
public page. (I sent out info about this on Friday.) Ditto for the 
document summary, meeting minutes, etc. Most of this content will be 
queried out of the Kavi database, which we can supplement with statis HTML.

 > o where we post (and compile) IPR disclosures?

Just as with the charters I will be maintaining this and setting up the 
links. Each TC will have a charter and a compilation of IPR 
declarations; we'll point to each in a consistent manner.

> o the membership that was uploaded is out of date; how we add
>   new prospective members and set the dates when they will
>   become voting members?

This is a new Kavi feature that we'll be installing later this week.

> Finally, could you please provide the kavi roll-out schedule and 
> milestones including for example the date when the system goes 
> production and to other phased out?

I sent this out in my message on Friday. We're still looking at 13 March 
for the launch date. Customized features will be installed later this 
week, and we're continuing to update membership rosters and create 
subcommittees.

 > 1. Referencing document links in a version agnostic way. There are many
 > situations, where you want to host a document in such a way that the
 > link to it is version agnostic - as such, the link is always the same.
 > Two situations come to mind:
[snip]
 >  What I've found is that every time a document is updated, the
 >  links referencing it changes as a result of versioning. For
 >  example, if I were to update the "Committee Specifications" page
 >  (the first link), the link to
[snip]
 >  B. It is customary for specs to have both a "current" and a
 >  "version insensitive" link in the header.
[snip]
 >  In both cases the links need to be a) version invariant and b)
 >  need to be "hard-coded". We need to determine and control what a
 >  link to a document is going to be. As such, we need to be able to
 >  set a fixed link on a doc that is stored on a kavi system. Not
 >  having this capability will make it difficult to use kavi to host
 >  committee specs.

The doc repository will track each individual object. I don't know of 
any way using just the repository to substitute different files for a 
single entry, and in fact I don't think that we want to; repositories 
are supposed to store all versions of a doc. The way to do this is to 
modify the static HTML that will appear on the Documents section of your 
public page; e.g. "The current version of this file is <pointer>".

 > 2. Referencing content from html pages stored on kavi.
 >  Some of the content we'd like to host on kavi references local
 >  content. For example,
 > 
http://kavi.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/105/bps.htm
 >  has the following reference:
 >   <img src="top_of_page.gif" width="43" height="25" border="0"
 >   alt="TOP OF PAGE"></a></font></p>
 >  The source image "top_of_page.gif" is collocated with the document
 >  but does not render on the page (most likely due to version /
 >  document path issues).
 >  Could you please provide info explaining how to reference this
 >  content? The answer to this is likely dependent on the answer to
 >  the above.

I don't know the answer to this. Chris?


-Karl

=================================================================
Karl F. Best
Vice President, OASIS
office  +1 978.667.5115 x206   mobile +1 978.761.1648
karl.best@oasis-open.org   http://www.oasis-open.org