hproduct-issues

HP1 - hProduct vs hListing regarding "price" / "quantity" / "shipping" fields

• open issue! 2008-12-17 raised by NicolasLeroy

• 1. In the "out of scope" section, it is explained: _"This microformat does not intend to replicate any of the content proposed within hListing and would defer all money/transactional matters to that microformat"_
  2. However, in the hProduct schema, we have the following fields:
     • "price. optional. floating point number. can be further refined by type (msrp, regular, sale, clearance)" => if the price is the retailer price, then it should be delegated to hListing. We could imagine it represents the "manufacturer" price (which could be different from the retailer price) ; in this case, it should clearly be explained in the schema definition.
     • I would say there is also ambiguity between the responsibilities of hProduct vs hListing for the following fields: quantity / shipping
       • Response by Jay Myers, 2008-02-16: I believe everyone agrees that we would borrow price from hListing for hProduct spec. I will explain the concept further in the schema.
       • Response by Jay Myers, 2008-02-16: I don't follow the quantity/ shipping issue. I don't see either of these on hListing, unless the concepts are somehow embedded in other attributes. Can you elaborate on what the ambiguity is? (Paul Lee: If there's no objection here, may I suggest updating the price reference and keeping quantity and shipping as is?])
     • +1 I agree with NicholasLeroy, anything price or transaction related should be left out of hProduct 0.1, and instead develop recipes / mark-up examples showing use of hListing with hProduct. We need to strongly resist and fight the tendency to include "just one more field" to individual formats and instead push to use formats as building blocks. Tantek 23:41, 18 February 2009 (UTC)
       • Response by Jay Myers, 2009-03-03: If price should be left to hListing, should hAudio be modified not to include "price"?
     • I am going to add price back into the hProduct spec. Price is an attribute of a product. We should be able to use microformats either standalone or as building blocks in combination with other formats. On price I'm thinking specifically of product manufacturer sites who may not be commerce enabled and are listing their products for informational purposes. In this case, they would not be using hListing, as there would be no transaction taking place. Leaving the price attribute out would ignore a major product attribute (in 99% of product sites, per hproduct examples analysis).

HP2 - FN should be used instead of N for product title

• open issue! 2009-02-17 raised by ManuSporny

• Why is n used instead of fn for the title of the product? hCard and hAudio both use fn for the formatted name of the product. n is usually an optimization.
• +1 hProduct should use "fn" for the name of the product. Tantek 23:41, 18 February 2009 (UTC)
  • Response by Jay Myers, 2008-03-03: "n" will be changed to "fn" in the next version of the schema
• "fn" is hardly semantic, even though commonly deployed - surely "formatted-name" is truer to the principles of "humans-first, machines second" --Wowitim 12:59, 28 March 2009 (UTC)

HP3 - BUY duplicates functionality of PAYMENT from hAudio

• open issue! BUY duplicates functionality of PAYMENT from hAudio2009-02-17 raised by ManuSporny

• buy is duplicating the functionality of payment from hAudio.
  • Response by Paul Lee, 2008-02-18: From the payment page: "RelPayment is a microformat for making exchanges of support (be it financial or otherwise) possible. By adding rel="payment" to a hyperlink a page indicates that the destination of that hyperlink provides a way to show or give support for the current page. For example to give financial support to the owner of the current page. One of the goals with this microformat is to give content aggregators such as RSS readers a way to extract these support links and give them special attention (such as displaying a standard button along with the content)." First, this seems like a simple exercise for blogs, etc.; but the transaction process for shopping sites is typically considerably more complex. Usually, the actual payment URI is toward the end of the cart checkout process, the entry to which "buy" is intended to direct to the beginning of. Second, there is the potential for confusion when using payment, since "payment" in the shopping space often refers to payment methods, e.g., credit card, check, etc.
• +1 but in a different way. BUY/PAYMENT should both be out of scope for hProduct, and only be in hListing per issue HP1 above. Tantek 23:41, 18 February 2009 (UTC)
  1. • Response by Jay Myers, 2009-03-03: Should these be in scope for hAudio then?

HP4 - Are all of the formats for PRICE in hProduct allowed

• open issue! 2009-02-17 raised by ManuSporny

• The way that price is used is iffy - do we allow anything but currency/amount in the compound statement?
• +1 PRICE should not be in hProduct per issue HP1. Tantek 23:41, 18 February 2009 (UTC)
  1. • Response by Jay Myers, 2009-03-03: Should other microformats (thinking hAudio) be modified not to include "price"?

HP5 - The format for the contents of SHIPPING are vague

• open issue! 2009-02-17 raised by ManuSporny

• Seems like shipping could be abused quite a bit, resulting in a term that is fairly useless as time moves on.
• +1 agreed and I think SHIPPING belongs in hListing (not in hProduct) as it applies to a particular transaction/offering, and is not intrinsic to the product itself. Tantek 23:41, 18 February 2009 (UTC)

HP6 - P-V seems like a catch-all for hProduct

• open issue! 2009-02-17 raised by ManuSporny

• p-v seems like a catch-all, shoe-horn attempt at making the microformat infinitely scalable? Is this really useful?
  • Response by Paul Lee, 2008-02-18: IIUC, part of the reason why hproduct has been under discussion for quite awhile is b/c of the debate between p-v vs. more defined attributes. p-v is quite helpful b/c the attributes users care about change over time. Take cameras, for instance. Did anyone care about megapixels 10 years ago? etc.
• +1 I strongly oppose p-v as it is nothing more than a circumvention of the microformats process and 80/20 principle of formalizing only common properties. microformats are NOT designed to be infinitely extensible. p-v is simply another source of Tower of Babel problems. When attributes change over time, then the microformat can be iterated/extended to include them, *when* publishing behavior on the web for the *data* of such attributes exceeds the required 80/20 usage per microformats process. That being said, if you really must include arbitrary property-value data, there is already a microformat for that: xoxo. Modularly include a xoxo child and that way the extension is contained in a specific structure that can be ignored by implementations. Tantek 23:41, 18 February 2009 (UTC)

HP7 - Lots of vocabulary terms, does the data really back this up?

• open issue! 2009-02-17 raised by ManuSporny

• There seem to be a great deal of vocab terms and the terms seem to be fairly loosely defined... are they all justified? Is there a file that we can analyze (like via microformalyze)?
  • Response by Paul Lee, 2008-02-18:The examples aren't necessarily an accurate reflection of how frequently attributes/data is used by retailers. In practice, model/mpn is used much more frequently than dimensions, both for retailer websites as well as retailer submissions to search and shopping engines. Defer to those with more experience/other data on version.
• +1. If you cannot justify a property, or are unsure about including it, or don't think it is necessarily an accurate reflection of how frequently the data is used, then leave it out per microformats principles. A "version" property was added to hReview for largely theoretical concerns, but has never been needed/used. So in practice (per experience), leave out "version". Tantek 23:41, 18 February 2009 (UTC)
  • Response by Jay Myers, 2008-03-03: I agree on both fronts here, I was surprised that model wasn't more prevalent in the research data, as it seems like an attribute that appears on nearly every product. Since "model" is often used as a type of identifier, it should be moved under the identifier attribute. "Version" will be taken out.

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>

Resolved Issues

Closed Issues

Related Pages