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


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-adopt-docs message

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

Subject: Re: FW: [Fwd: FW: [emergency-adopt-docs] EDXL Product Directory DataFields]

Thanks Carol,

I think you hit on the key fact: We're not ready to ask OASIS IT to go 
into production for us yet. We need to listen to the OASIS IT staff, 
including you, in more discussions about what options are reasonable and 
which might not be. It might also be wise to ask the vendor interop 
group their opinions.

The one thing that continues to stick with me is that if the initial 
sorting in either the BPEL or DITA models includes the full Product 
Description text box in each listing and there is a lot of white space. 
This pushes some vendor/products off the bottom of the first screen 
after initial sorting.

This puts the vendor at the bottom of the list in a distinct 
disadvantage. At a minimum, I think we should make as many 
vendor/products that match all criteria visible on the screen that 
follows the initial sorting.

A simple one line vendor/product name listing; using the same styling 
for emphasis that you suggest; based on the initial sorting criteria 
that gets as many as possible of the vendor/product names that qualify 
into the first screen would be more fair.

Those line items could link to the slightly larger product description 
box that could appear in place or in a smaller window or in a popup.

In fact it might be better if the browser window is automatically sized 
to fit all or the most possible qualifying vndor/product names so that 
no vendor ends up in the "Xavier's ZenWidget" position as an example of 
the disadvantage of the alphabetized listing. In the two examples we 
looked at, a vendor could match all sorting criteria and still be 
invisible off the bottom of the page.

We did not reach consensus today, so we still need to work through this.


Carol Geyer wrote:
> I agree with most of what's in Patrick's spreadsheet, with the following
> caveats:
> Line 9: 'Company logo'--this will only apply to OASIS Sponsor-level members.
> Line 15: 'InterOp Demo link'--I thought this was a good idea when we
> discussed it, but when it comes to implementation, I can see a lot of
> problems. What pages would we link to? Some interops have a posted slide
> presentation or video that would be good, but others interops, such as the
> one we did at NIEM,
> http://events.oasis-open.org/home/ei-summit/2009/participants don't provide
> much really useful info after-the-fact. Also, I'm not visualizing how these
> links would be displayed. If we continue our practice of 3-5 interops a
> year, this list could get really lengthy. I recommend we stick with a simple
> yes/no for 'OASIS Interop Participant' at least to start.
> Line 17: 'Link to Vendor's RKB entry'--Who would input this, the vendor? How
> would it be displayed on the page? Again, the yes/no checkbox for this is
> useful as a filter, but it would be much more straightforward for vendors
> (who want to) to include this link in their Product Description text box.
> Line 19: 'Link to vendor's STEP evaluation report'--Ditto
> Patrick's asks, Does the Vendor make one entry into the database for each
> product-spec-version? Or does Vendor make one entry into the database for
> each product & be able to select all spec-versions that are supported?	
> I say the later. If one product supports multiple versions of a spec, the
> product gets one listing in the directory but that listing has multiple
> checkboxes in the "Specs" filter.
> ~Carol
> -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com] 
> Sent: Tuesday, February 23, 2010 12:50 PM
> To: Carol Geyer
> Subject: [Fwd: FW: [emergency-adopt-docs] EDXL Product Directory Data
> Fields]
> Hi Carol,
> I am forwarding the message below which includes Patrick's message of
> January 18, 2010 with the attached spreadsheet. We approved this message in
> our Collateral and Documents SC meeting today.
> Thanks,
> Rex Brooks
> -------- Original Message --------
> Subject: 	FW: [emergency-adopt-docs] EDXL Product Directory Data
> Fields
> Date: 	Tue, 23 Feb 2010 11:05:12 -0500
> From: 	Patrick Gannon <pgannon@warningsystems.com>
> To: 	<rexb@starbourne.com>
> Rex,
> Please forward the email below to Carol, with attachment, which was approved
> by the C&D SC on 23 Feb to be added to the EM Product Director Requirements.
> The  C&D SC also requested that the assigned OASIS IT person join the next
> SC call at 10am ET on 9 Mar to discuss these requirements with the SC
> including the questions posed in my email of 18 Jan.
> Patrick
> -----Original Message-----
> From: Patrick Gannon [mailto:pgannon@warningsystems.com]
> Sent: Monday, January 18, 2010 1:03 PM
> To: emergency-adopt-docs@lists.oasis-open.org
> Subject: [emergency-adopt-docs] EDXL Product Directory Data Fields
> Rex,
> After struggling to answer the questions today about what the search should
> look like, I stepped back to consider what data a vendor would have
> available to enter into the product directory. Attached is  DRAFT of some
> thoughts on those data fields.  Doing this helped me to see that we need to
> engage with the OASIS IT staff person on questions about whether the
> available Drupal software models can support relational data fields with
> one-to-many relationships.  This will determine whether a vendor needs to
> make one entry for each of their products and then be able to select
> multiple specs/version from a drop-down list, or whether they are limited to
> selecting only one spec-version per product entry.  See example I included
> in the attached spreadsheet.
> Are there other data fields needed?  
> Patrick Gannon
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-898-0670
> ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670

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