hatom-issues - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:23:53Z

Replace <entry-title> with {{DISPLAYTITLE:}}

← Older revision		Revision as of 16:23, 18 July 2020
Line 1:		Line 1:
	~~<entry-title>~~ hAtom issues ~~</entry-title>~~		{{DISPLAYTITLE: hAtom issues }}
	These are externally raised issues about [[hAtom]] 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 [[hAtom]] 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.

Tantek: Reverted edits by Gowrvw (Talk) to last version by Tantek

2013-08-25T19:49:17Z

Reverted edits by Gowrvw (Talk) to last version by Tantek

Show changes

Gowrvw at 19:47, 25 August 2013

2013-08-25T19:47:29Z

Show changes

Tantek: Reverted edits by ABIDEEN10 (Talk) to last version by Bmearns

2013-04-07T04:50:41Z

Reverted edits by ABIDEEN10 (Talk) to last version by Bmearns

Show changes

ABIDEEN10 at 04:08, 7 April 2013

2013-04-07T04:08:05Z

Show changes

Bmearns: /* entry-title optionality */ Propose "null" value if missing

2013-02-25T19:33:45Z

entry-title optionality: Propose "null" value if missing

← Older revision		Revision as of 19:33, 25 February 2013
Line 65:		Line 65:
	**** +1 [[User:WebOrganics\|Martin McEvoy]] see: [http://www.atomenabled.org/developers/syndication/#requiredEntryElements Required Entry Elements] from Atom Enabled.		**** +1 [[User:WebOrganics\|Martin McEvoy]] see: [http://www.atomenabled.org/developers/syndication/#requiredEntryElements Required Entry Elements] from Atom Enabled.
	**** [[User:DavidJanes]] what should it be then, if physically representing it is optional? Since Atom makes this a SHOULD and not a MUST (I'm not shouting, just following RFC convention), and we're assuming there's a good reason for the entry-title not to be present in the first place, why not an empty string?		**** [[User:DavidJanes]] what should it be then, if physically representing it is optional? Since Atom makes this a SHOULD and not a MUST (I'm not shouting, just following RFC convention), and we're assuming there's a good reason for the entry-title not to be present in the first place, why not an empty string?
	***** [[User:WebOrganics\|Martin McEvoy]] entry:title is a required attribute of atom at both feed and entry level, in both instances it says "Contains a human readable title" (a requirement) an empty string is not anything human readable (personal oppinion), maybe hAtom 0.2 should only recommend that the value of entry-title "should" not be an empty string.		***** [[User:WebOrganics\|Martin McEvoy]] entry:title is a required attribute of atom at both feed and entry level, in both instances it says "Contains a human readable title" (a requirement) an empty string is not anything human readable (personal oppinion), maybe hAtom 0.2 should only recommend that the value of entry-title "should" not be an empty string.
			*** the value should be NULL.
			**** +1 [[User:Bmearns\|Bmearns]]: Whatever that may mean to the specific handler. A blank string implies that a handler which generates HTML content, for instance, should generate <code><H1></H1></code>, as opposed to just omitting the title all together.
	*** ... your proposal here, your vote in a sublist ...		*** ... your proposal here, your vote in a sublist ...
	* include in hAtom 0.2		* include in hAtom 0.2
	** +1 [[User:DavidJanes]]		** +1 [[User:DavidJanes]]
	** +1 [[User:WebOrganics\|Martin McEvoy]]		** +1 [[User:WebOrganics\|Martin McEvoy]]
			** +1 [[User:Bmearns\|Bmearns]]

	==== updated optionality ====		==== updated optionality ====

Bmearns: /* entry-title optionality */ +1 vote for optional title

2013-02-25T19:29:33Z

entry-title optionality: +1 vote for optional title

← Older revision		Revision as of 19:29, 25 February 2013
Line 56:		Line 56:
	*** +1 [[User:DavidJanes]]		*** +1 [[User:DavidJanes]]
	*** +1 [[User:WebOrganics\|Martin McEvoy]] but not recommended.		*** +1 [[User:WebOrganics\|Martin McEvoy]] but not recommended.
			*** +1 [[User:Bmearns\|Bmearns]] I think this format has much broader application without this limitation. I'm thinking, for instance, of the Facebook news feed, or a twitter feed, both of which could use this microformat but do not in general have titles for each post.
	*** ... your vote here ...		*** ... your vote here ...
	** if this element is not in the [[hatom#In_General\|physical model]], the logical model value should be		** if this element is not in the [[hatom#In_General\|physical model]], the logical model value should be

TobyInk: /* No defined parsing rule for updated timestamps in inselements */ swignition and html::microformats supports some of this

2010-03-21T23:00:29Z

No defined parsing rule for updated timestamps in inselements: swignition and html::microformats supports some of this

← Older revision		Revision as of 23:00, 21 March 2010
Line 21:		Line 21:
	# Proposed resolution. Document a parsing rule for the <code>ins</code> element, stating that for an <code>ins</code> (or <code>del</code>) element with class of <code>updated</code>, the value of the <code>datetime</code> attribute should be used as the value.		# Proposed resolution. Document a parsing rule for the <code>ins</code> element, stating that for an <code>ins</code> (or <code>del</code>) element with class of <code>updated</code>, the value of the <code>datetime</code> attribute should be used as the value.
	#* +1 This sounds like a good idea and something worthy of being incorporated into [[hcard-parsing#more_semantic_exceptions]] (which is where the core of generic microformat parsing is currently documented) for special handling for all datetime properties. [[User:Tantek\|Tantek]] 17:43, 21 January 2010 (UTC)		#* +1 This sounds like a good idea and something worthy of being incorporated into [[hcard-parsing#more_semantic_exceptions]] (which is where the core of generic microformat parsing is currently documented) for special handling for all datetime properties. [[User:Tantek\|Tantek]] 17:43, 21 January 2010 (UTC)
			# This has been supported by Swignition for well over a year, and is supported by HTML::Microformats. [[User:TobyInk\|TobyInk]] 23:00, 21 March 2010 (UTC)
	# Proposed extended resolution: As well as the above explicit parsing rule, an implication parsing rule stating that where <code>update</code> is not explicitly marked up, the parser may aggregate all <code>ins</code> and <code>del</code> elements in the <code>hentry</code>, and use the most recent <code>datetime</code> attribute content as the <code>updated</code> value.		# Proposed extended resolution: As well as the above explicit parsing rule, an implication parsing rule stating that where <code>update</code> is not explicitly marked up, the parser may aggregate all <code>ins</code> and <code>del</code> elements in the <code>hentry</code>, and use the most recent <code>datetime</code> attribute content as the <code>updated</code> value.
	#* +1 Brilliant. Indeed right now 'updated', if missing, is implied from the 'published' property. Suggested change to that rule (incorporating your proposal) : if 'updated' is missing, use the latest in time value of: the 'published' property value, and the 'datetime' attributes of all ins and del elements inside the hentry. [[User:Tantek\|Tantek]] 17:43, 21 January 2010 (UTC)		#* +1 Brilliant. Indeed right now 'updated', if missing, is implied from the 'published' property. Suggested change to that rule (incorporating your proposal) : if 'updated' is missing, use the latest in time value of: the 'published' property value, and the 'datetime' attributes of all ins and del elements inside the hentry. [[User:Tantek\|Tantek]] 17:43, 21 January 2010 (UTC)
Line 32:		Line 33:
	<div class="entry-content discussion issues">		<div class="entry-content discussion issues">
	* <strong class="entry-title">Should we talk about parsing of <time> element?</strong>. I use this element to mark up published on my blog. It is not supported by any implementation that I know of. Should implementors be encouraged to add this? Should the spec talk about it as an alternative to datetime-design-pattern? That page currently says to check the hcal issues, but there is nothing there about it.		* <strong class="entry-title">Should we talk about parsing of <time> element?</strong>. I use this element to mark up published on my blog. It is not supported by any implementation that I know of. Should implementors be encouraged to add this? Should the spec talk about it as an alternative to datetime-design-pattern? That page currently says to check the hcal issues, but there is nothing there about it.
			** Swignition has supported this for well over a year. It's also been supported in HTML::Microformats since version 0.00_00. [[User:TobyInk\|TobyInk]] 23:00, 21 March 2010 (UTC)
	</div>		</div>
	</div>		</div>

Singpolyma: element useage

2010-03-20T22:40:58Z

<time> element useage

@@ Line 23: / Line 23: @@
 *#* Proposed extended resolution: As well as the above explicit parsing rule, an implication parsing rule stating that where <code>update</code> is not explicitly marked up, the parser may aggregate all <code>ins</code> and <code>del</code> elements in the <code>hentry</code>, and use the most recent <code>datetime</code> attribute content as the <code>updated</code> value.
 *#** +1 Brilliant. Indeed right now 'updated', if missing, is implied from the 'published' property.  Suggested change to that rule (incorporating your proposal) : if 'updated' is missing, use the latest in time value of: the 'published' property value, and the 'datetime' attributes of all ins and del elements inside the hentry. [[User:Tantek|Tantek]] 17:43, 21 January 2010 (UTC)
 ===2009===

Tantek: /* No defined parsing rule for updated timestamps in inselements */ +1

2010-01-21T17:43:17Z

No defined parsing rule for updated timestamps in inselements: +1

← Older revision		Revision as of 17:43, 21 January 2010
Line 20:		Line 20:
	*# hAtom includes the <code>updated</code> property for the last modification/revision date of an entry. HTML already has an <code>ins</code> element for marking up inserted changes to text, and that element has a <code>datetime</code> attribute, to document the date and time of the change. Currently, hAtom and microformats have no model for parsing the data from that <code>datetime</code> attribute, but the document semantics suggest it would be an appropriate source for the <code>updated</code> property. Example: <http://blog.benward.me/post/250674456>		*# hAtom includes the <code>updated</code> property for the last modification/revision date of an entry. HTML already has an <code>ins</code> element for marking up inserted changes to text, and that element has a <code>datetime</code> attribute, to document the date and time of the change. Currently, hAtom and microformats have no model for parsing the data from that <code>datetime</code> attribute, but the document semantics suggest it would be an appropriate source for the <code>updated</code> property. Example: <http://blog.benward.me/post/250674456>
	# Proposed resolution. Document a parsing rule for the <code>ins</code> element, stating that for an <code>ins</code> (or <code>del</code>) element with class of <code>updated</code>, the value of the <code>datetime</code> attribute should be used as the value.		# Proposed resolution. Document a parsing rule for the <code>ins</code> element, stating that for an <code>ins</code> (or <code>del</code>) element with class of <code>updated</code>, the value of the <code>datetime</code> attribute should be used as the value.
			#* +1 This sounds like a good idea and something worthy of being incorporated into [[hcard-parsing#more_semantic_exceptions]] (which is where the core of generic microformat parsing is currently documented) for special handling for all datetime properties. [[User:Tantek\|Tantek]] 17:43, 21 January 2010 (UTC)
	# Proposed extended resolution: As well as the above explicit parsing rule, an implication parsing rule stating that where <code>update</code> is not explicitly marked up, the parser may aggregate all <code>ins</code> and <code>del</code> elements in the <code>hentry</code>, and use the most recent <code>datetime</code> attribute content as the <code>updated</code> value.		# Proposed extended resolution: As well as the above explicit parsing rule, an implication parsing rule stating that where <code>update</code> is not explicitly marked up, the parser may aggregate all <code>ins</code> and <code>del</code> elements in the <code>hentry</code>, and use the most recent <code>datetime</code> attribute content as the <code>updated</code> value.
			#* +1 Brilliant. Indeed right now 'updated', if missing, is implied from the 'published' property. Suggested change to that rule (incorporating your proposal) : if 'updated' is missing, use the latest in time value of: the 'published' property value, and the 'datetime' attributes of all ins and del elements inside the hentry. [[User:Tantek\|Tantek]] 17:43, 21 January 2010 (UTC)

	===2009===		===2009===