hlisting-issues: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (Replace <entry-title> with {{DISPLAYTITLE:}})
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<entry-title> hListing Issues </entry-title>
{{DISPLAYTITLE: hListing Issues }}


These are externally raised issues about [[hlisting|hListing]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.  
These are externally raised issues about [[hlisting|hListing]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.  
Line 33: Line 33:


== issues ==
== issues ==
=== 2014 ===
{{OpenIssue}}
* 2014-11-17 raised by [[User:ChiefRA|Arthur Rădulescu]]
*# We should create Directives for hListing consumers (and also for Google?): directives on how hListing should be interpreted and consumed, rules which CAN be applied to hListing validators too.
{{OpenIssue}}
* 2014-11-17 raised by [[User:ChiefRA|Arthur Rădulescu]]
*# There is an ambiguity regarding [http://microformats.org/wiki/hlisting#Property_Details hListing Property Details]: on the second line, named '''Listing type::''' it sais: "This required field" but it is not mentioned in the main Properties and there is no field on the above main [http://microformats.org/wiki/hlisting#Properties hListing Properties]. However, there is a mix of properties on the second listed property called: "''listing action.'' optional." 
*#* Tried to fix all of these in the [http://microformats.org/wiki/hlisting-duplicated-for-discussions hlisting duplicated draft page] - read it by comparison 1-on-1 with the [http://microformats.org/wiki/hlisting default hListing page]. These 2 fields should now be understandable from implementation POV.
{{OpenIssue}}
* 2014-11-17 raised by [[User:ChiefRA|Arthur Rădulescu]]
*# I presume this mandatory field called '''Item type''' should be added next to the other properties of the hListing next to the [http://microformats.org/wiki/hlisting#Properties hListing Properties].
*#* Tried to fix this in the [http://microformats.org/wiki/hlisting-duplicated-for-discussions hlisting duplicated draft page] - read it by comparison 1-on-1 with the [http://microformats.org/wiki/hlisting default hListing page]. This field should now be understandable from implementation POV.
{{OpenIssue}}
* 2014-11-17 raised by [[User:ChiefRA|Arthur Rădulescu]]
*# One of the main obstacles for hListing usage is the lack of implementation examples on our end (real in-code implementation) for the 2-words properties. ex. "item info": tag which should encapsulate all the details like hCard | (fn || url || photo || geo || adr)? Should it be exactly class="item info" OR class="item-info"? This needs to be defined as it has to keep encapsulated within all the details of the item.
{{OpenIssue}}
* 2014-11-17 raised by [[User:TomMorris|Tom Morris]]
*# The '''version''' property should be deprecated. No other Microformat (classic or [[microformats-2|new]]) has used explicit versioning and it seems out of sync with the way we have thus far built microformats specifications. It also seems incompatible with the [http://www.w3.org/TR/html-design-principles/#compatibility Compatibility section of the HTML Design Principles] which we ought to attempt to follow where possible.


<div class="hentry">
<div class="hentry">
{{OpenIssue}}
<span class="entry-summary author vcard">
<span class="entry-summary author vcard">
  <span class="published">2010-09-19</span>  
  <span class="published">2010-09-19</span>  

Latest revision as of 16:26, 18 July 2020


These are externally raised issues about hListing with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

IMPORTANT: Please read (or in this case create ;) ) the hListing FAQ before giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well.

Please add new issues to the top of the list. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

closed issues

When this section gets too big, it can be moved to hlisting-issues-closed. Issues that are resolved, with accepted resolutions (in some cases simply accepting the entire noted issue), and with completion of respective edits to the draft or related documents.

resolved issues

Issues that have been resolved but may have outstanding to-do items. When this section gets too big, it can be moved to hlisting-issues-resolved.

2007

  • 2007-07-21 raised by User:RobManson
    1. The only discussion I could find relating to payment method for hListing was in the tag section. Wouldn't rel-payment be a natural fit with hListing?

2008

  • 2008-04-07 raised by User:Eazytiger
    1. When hListing is used for eCommerce products, is there any provision for product variations (eg. sizes) that will affect the price? I'm not aware of a precedent for variations in another microformat.
      • ACCEPTED FAQ. A product variation that affects the price should be included in the description of the item, and perhaps as a tag on the item as well. This should be added to hlisting-faq Tantek 10:18, 5 August 2009 (UTC)
  • 2008-08-26 raised by TobyInk
    1. The example given in the spec includes an invalid hCard. (Missing fn.)
      • ACCEPTED. The example has been fixed to reference the "adr" directly for the location, which was the intent of the example. Tantek 10:18, 5 August 2009 (UTC)

2009

  • 2009-03-10 raised by JayMyers
    1. Per the discussions raised in the hProduct issues list, are there any provisions for providing transactional details like "shipping" or "buy/payment" attributes?
      • ACCEPTED BRAINSTORMING. Consider adding transactional details like "shipping" or "buy/payment" attributes or something similar for an iteration of hListing, request added to hlisting-brainstorming. Tantek 10:18, 5 August 2009 (UTC)

issues

2014

open issue!

  • 2014-11-17 raised by Arthur Rădulescu
    1. We should create Directives for hListing consumers (and also for Google?): directives on how hListing should be interpreted and consumed, rules which CAN be applied to hListing validators too.

open issue!

  • 2014-11-17 raised by Arthur Rădulescu
    1. There is an ambiguity regarding hListing Property Details: on the second line, named Listing type:: it sais: "This required field" but it is not mentioned in the main Properties and there is no field on the above main hListing Properties. However, there is a mix of properties on the second listed property called: "listing action. optional."

open issue!

open issue!

  • 2014-11-17 raised by Arthur Rădulescu
    1. One of the main obstacles for hListing usage is the lack of implementation examples on our end (real in-code implementation) for the 2-words properties. ex. "item info": tag which should encapsulate all the details like hCard | (fn || url || photo || geo || adr)? Should it be exactly class="item info" OR class="item-info"? This needs to be defined as it has to keep encapsulated within all the details of the item.

open issue!

  • 2014-11-17 raised by Tom Morris
    1. The version property should be deprecated. No other Microformat (classic or new) has used explicit versioning and it seems out of sync with the way we have thus far built microformats specifications. It also seems incompatible with the Compatibility section of the HTML Design Principles which we ought to attempt to follow where possible.

2010-09-19 
raised by JulienChaumond

  • Indicate that transaction has taken place.

hlisting tells the world that someone is selling something, but shouldn't there be a way to express that someone bought (or rented, etc.) something, i.e. transaction has indeed taken place? (Think Blippy, Swipely, Apple's Ping, etc.). One way to go about it might be to add an optional datetime element specifying the transaction's date.

Template

Consider using this format (copy and paste this to the end of the list to add your issues; replace ~~~ with an external link if preferred) to report issues or feedback, so that issues can show up in hAtom subscriptions of this issues page. If open issues lack this markup, please add it.

Please post one issue per entry, to make them easier to manage. Avoid combining multiple issues into single reports, as this can confuse or muddle feedback, and puts a burden of separating the discrete issues onto someone else who 1. may not have the time, and 2. may not understand the issue in the same way as the original reporter.

<div class="hentry">
{{OpenIssue}} 
<span class="entry-summary author vcard">
 <span class="published">2011-MM-DD</span> 
 raised by <span class="fn">~~~</span>
</span>
<div class="entry-content discussion issues">
* <strong class="entry-title">«Short title of issue»</strong>. «Description of Issue»
** Follow-up comment #1
** Follow-up comment #2
</div>
</div>

see also