hproduct-issues

From Microformats Wiki
Revision as of 05:11, 18 February 2009 by ManuSporny (talk | contribs) (Added hProduct issues --manu)
Jump to navigation Jump to search

2008-12-17 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?
    1. 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.
    2. buy is duplicating the functionality of payment from hAudio.
    3. The way that price is used is iffy - do we allow anything but currency/amount in the compound statement?
    4. Seems like shipping could be abused quite a bit, resulting in a term that is fairly useless as time moves on.
    5. p-v seems like a catch-all, shoe-horn attempt at making the microformat infinitely scalable? Is this really useful?
    6. There seem to be a great deal of vocab terms and the terms seem to be fairly loosely defined for a microformat... are they all justified?

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>