Problématiques hProduct

HP1 - hProduct vs hListing concernant les champs "price" / "quantity" / "shipping"

• problématique ouverte ! 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 devrait être utilisé au lieu de N pour le titre du produit

• problématique ouverte ! 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 duplique la fonctionnalité PAYMENT de hAudio

• problématique ouverte ! 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 - Est-ce que tous les formats sont autorisés pour PRICE dans hProduct

• problématique ouverte ! 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 - Le format pour les contenus de SHIPPING sont vagues

• problématique ouverte ! 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 ressemble à un attrape-tout pour hProduct

• problématique ouverte ! 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 - Beaucoup de termes de vocabulaire, est-ce que la data remonte vraiment ça ?

• problématique ouverte ! 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.

HP8 - Pas de moyen clair d'inclure une hReview valide qui renvoie au hProduct comme étant son item

• problématique ouverte ! 2010-03-05 raised by GeorgeBrock

• An hProduct can include one or more hReviews. Each hReview requires an item, which should be the hProduct. The include-pattern prohibits references to an ancestor. Therefore it is not clear how to include a valid hReview in an hProduct.
  • Suggested by Tantek on IRC: The item-url property from item-license could be used to refer to the review's item without including it.
    • This suggestion "seems to introduce extra markup that's likely to be extraneous from an end-user point-of-view, and thus set to display:none by authors." — Toby Inkster on the mailing list
  • The review property could be removed altogether, and instead multiple product reviews could be marked up using a more generic container mechanism (see container-brainstorming). This would give a us consistent method of marking up multiple hReviews that apply to the same item, instead of a special case that only applied to hProduct. — GeorgeBrock 13:35, 17 April 2010 (UTC)

Problématiques résolues

HP1 - hProduct vs hListing concernant les champs "price" / "quantity" / "shipping"

• problématique résolue 2009-04-24 raised by JayMyers

• "quantity" and "shipping" have been removed from hproduct and transitioned to a new hlisting proposal. "price" has been retained, with the caveat that if hproduct is being used alone (eg., a non-commerce site who provides product information), without combining it with a microformat like hlisting, it is assumed that the price attribute represents the suggested manufacturers retail price. All transactional details (including transactional price) would be deferred to hlisting.

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

• problématique résolue 2009-04-24 raised by JayMyers

• changed in draft spec 0.2

HP3 - BUY duplicates functionality of PAYMENT from hAudio

• problématique résolue 2009-04-24 raised by JayMyers

• buy removed in draft spec 0.2

HP5 - The format for the contents of SHIPPING are vague

• problématique résolue 2009-04-24 raised by JayMyers

• shipping removed in draft spec 0.2

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

• problématique résolue 2009-04-24 raised by JayMyers

• p-v has been removed in draft spec 0.3 in favor of xoxo

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

• problématique résolue 2009-04-24 raised by JayMyers

• many attributes have been removed in draft specs 0.2 and 0.3. We believe the current number of attributes accurately represents a product object while providing adequate opportunity to be combined with other microformats for better overall semantic solutions.

Problématiques fermées

Gabarit

SVP, utilisez ce format (copiez et collez ceci à la fin de la liste pour ajouter vos problématiques ; remplacez ~~~ par un lien externe si vous préférez) pour rendre compte des problématiques ou réactions :

<div class="vevent">
* {{OpenIssue-fr}} <span class="summary vcard"><span class="dtstart">AAAA-MM-JJ</span> soulevée par <span class="fn">~~~</span></span>
<div class="description">
*# Voici la première problématique/réaction que je rencontre.
*# Voici la seconde problématique/réaction que je rencontre.
</div>
</div>