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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

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


Subject: Re: [xdi] Follow up from today's meeting


Chet,

Thank you for a highly detailed and very instructional message summarizing everything we discussed on Friday's telecon.

I have updated the proposed names of the proposed members of the XDI 1.0 spec suite on https://wiki.oasis-open.org/xdi/XdiOneSpecs.

However the question of packaging—plus the evolution of some of the work in these specs since we drafted this page—leads me to suggest that the TC have a follow-on discussion on our next telecon about which specs we are ready to request a template for.

So: hang tough until this Friday's telecon and we'll be back to you after that.

Thanks,

=Drummond  


On Fri, Jun 14, 2013 at 1:03 PM, Chet Ensign <chet.ensign@oasis-open.org> wrote:
Drummond et al - 

Thanks for inviting us to the meeting today to talk with you all about the best path forward for the XDI Work Products. I think we arrived at a solution that - perhaps not surprising for your TC - explores a new way to manage the work progression for specs developed in multiple parts. 

To recap and ensure that I understood this correctly: 

- We used the contents as laid out on the XDI specs page as the model: https://wiki.oasis-open.org/xdi/XdiOneSpecs 

- We agreed that initially, you all will advance each of the documents as an individual Work Product. So, for example, you will have XDI Graph Model Version 1.0 Committee Specification Draft 01, XDI Serialization Version 1.0 Committee Specification Draft 01, etc. (You may approach the names in some other variant but that is the general notion.) 

These will appear in the OASIS Library hierarchy something like this: 

docs.oasis-open.org/xdi/
  ... xdi-graph-model/
      ... v1.0/
          ... csd01/ etc. 
              ... schemas/ (in other words, associated artifacts to graph-model, etc.) 
  ... xdi-serialization/
     ... v1.0/
         ... csd01 
  ... xdi-signatures/ 
    ... v1.0/ 
        ... csd01 


At a future date, when you all feel the work is sufficiently mature, you can (if you decide to do so) create a new, multi-part Work Product based on these individual WPs. This would be something like XDI Core Specification Version 1.0 and would have parts with titles like XDI Core Specification Version 1.0 Part 1: Overview, XDI Core Specification Version 1.0 Part 2: Graph Model, XDI Core Specification Version 1.0 Part 4: API 

In the OASIS Library, the hierarchy will be something like 

  ... xdi-core/
      ... v1.0/
          ... csd01/ 
              ... part1-overview/
              ... part2-graph-model/
             etc. 

The Work Product now would be XDI Core Specification Version 1.0. This work product would have to advance through the required stages: Committee Spec Draft, Public Review Draft, Committee Spec, Candidate OASIS Standard, and OASIS Standard. The key though is that now, going towards the OS vote - you would be managing and voting on *one* WP - the multi-part spec - and you would ultimately present the membership with a vote on one Candidate OASIS Standard.     

This seems like an excellent solution for the XDI TC. The advantages to this approach include: 

- Each initial WP can evolve & progress at its own pace without being dependent on the others 
- Each can achieve Committee Specification on its own pace, triggering the coverage of the OASIS IPR commitments when each is ready 
- The TC can gain experience working with the Work Products and the spec in a more nimble manner while going through the early steps of documenting them 
- When you are ready to proceed towards OASIS Standard, you only present the membership with a single vote, instead of 7 or 8. 

The only disadvantage we noted was that TC members or external reviewers might find issues in the combined WP because they see it all together for the first time. The TC can manage this in part by keeping everyone apprised of the other parts and making sure to encourage people to look across the collection even when they are reviewing an initial single part CS. 

Next steps: 

I think the best next step is for us to work together to start setting up the filenames, URLs and other metadata associated with the set of Work Products that you are ready to start on. 

Even though you will be working in the Docbook template, you will need to have the metadata to include as part of the cover pages in your work. 

The best way to do that is to submit a template request for each Work product. The ticket for requesting a template is at https://www.oasis-open.org/resources/tc-admin-requests/work-product-registration-template-request 

We will give you templates in Word or Open Office (your choice). The templates will give your editors the model for what to put into the Docbook files - the urls to use, etc. - and you'll be able to look at your output and compare it to the template to make sure you're getting it right. 

This will also let us all get in alignment on the work titles, filenames and urls in docs.oasis-open.org from the beginning. 

Let me know if you have any questions on any of this. Personally, I am looking forward to learning more about XDI as we go forward as I certainly see that it may have value for OASIS in the future. 

Best regards, 

/chet 



--

/chet 
----------------
Chet Ensign
Director of Standards Development and TC Administration 
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Primary: +1 973-996-2298
Mobile: +1 201-341-1393 

Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html 

TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin

Follow OASIS on:
LinkedIn:    http://linkd.in/OASISopen
Twitter:        http://twitter.com/OASISopen
Facebook:  http://facebook.com/oasis.open



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