value-class-pattern-issues: Difference between revisions
(→Depth of Parsing: Added another depth of parsing example) |
m (Replace <entry-title> with {{DISPLAYTITLE:}}) |
||
(24 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
{{DISPLAYTITLE:Value Class Pattern Issues}} | |||
This page documents issues with the [[value-class-pattern]] specification before 2016-06-20. | |||
As the [[value class pattern]] is now a required feature of the [[microformats2-parsing]] specification: | |||
{{warn|Please add new issues to [https://github.com/microformats/microformats2-parsing/issues GitHub issues], prefixed with "vcp:"}} | |||
See [[microformats2-parsing#change_control|change control]] for how to move new issues forward. | |||
<!-- | |||
{{warn|Note: all current issues resolved as of 2016-??-??}} | |||
* Pending edits to this page, and the [[microformats2-parsing]] specification. | |||
--> | |||
__TOC__ | |||
==Open Issues== | ==Open Issues== | ||
Line 10: | Line 20: | ||
===Excluded Fields=== | ===Excluded Fields=== | ||
<div class='discussion issues'> | |||
* '''There seem to be some properties within which value excerpting is NOT allowed (or ''should not'' be allowed!)''' e.g. "type" in hCard. [[User:TobyInk|TobyInk]] 07:38, 22 May 2008 (PDT) | |||
** You mean <code>type</code> as a sub-property of <code>tel</code>? That's one of the identified [[machine-data]] items that needs a means of including the publisher's choice text along with the microformat specified one. Not to conflate two separate issues, but just noting that separation of <code>type</code> text and <code>type value</code> needs to be handled somewhere, and value-excerption-pattern ''could'' be considered as part of the solution. [[User:BenWard|BenWard]] 07:54, 22 May 2008 (PDT) | |||
** Some fields make sense to exclude this, as it seems unintuitive, and can be used to avoid many of nested-microformat problems that may avoid a messier mfo pattern. E.g. <code>entry-summary</code> and <code>entry-content</code> in [[hAtom]], both could very feasibly have nested formats or any kind, but doesn't strike me as useful to segregate into "value" at all. [[User:BenWard|BenWard]] 10:41, 6 Jun 2008 (PDT) | |||
** Total other alternative, make value-excerption opt-in. Would need a bit of effort to go through all the specs and clarify, but actually might make more sense. It's a useful pattern for some properties (especially those with data patterns). [[User:BenWard|BenWard]] 10:41, 6 Jun 2008 (PDT) | |||
** Setting the rules over depth-of-parsing (see below) to children-only would obviate the remaining need for this issue. | |||
</div> | |||
===White-space behavior when concatenating value nodes=== | |||
<div class='discussion issues'> | |||
* '''We specify that no characters get inserted between concatenated occurrences of ‘value’'''. Need to audit all properties to ensure that this behavior would be correct in all cases. | |||
** Possibly specify that individual properties can override this behavior, specifying a separator character. | |||
** Possibly specify that this should be a provision of parsing implementations, so as to maintain flexibility for future publishing. | |||
===White-space | </div> | ||
We specify that no characters get inserted between concatenated occurrences of ‘value’. Need to audit all properties to ensure that this | |||
Possibly specify that individual properties can override this | |||
===Depth of Parsing=== | ===Depth of Parsing=== | ||
Currently any descendent is parsed, which causes issues if a microformat field using the value-excerption-pattern is nested within another. | '''Currently any descendent is parsed''', which causes issues if a microformat field using the value-excerption-pattern is nested within another. | ||
Example: | Example: | ||
<pre | <pre><div class="hentry vevent"> | ||
<h1 class="entry-title summary">Party on Sunday!</h1> | <h1 class="entry-title summary">Party on Sunday!</h1> | ||
<div class="updated published">Tuesday <span class="value">2008-06-17</span></div> | <div class="updated published">Tuesday <span class="value">2008-06-17</span></div> | ||
<p class="entry-content description">We're having a party on <span class="dtstart">Sunday, at 7pm! <span class="value">2008-06-22T19:00:00+0100</span></span>. Please bring your friends!</p> | <p class="entry-content description">We're having a party on <span class="dtstart">Sunday, at 7pm! | ||
</div> | <span class="value">2008-06-22T19:00:00+0100</span></span>. Please bring your friends!</p> | ||
</div></pre> | |||
In this example, hAtom and hCalendar are interleaved. The DTSTART property of the event is contained within the entry-content of the hAtom entry, using the value-excerption-pattern to include the machine-data datetime. However, with full descendent parsing, the hAtom model will come out as the following: | In this example, hAtom and hCalendar are interleaved. The DTSTART property of the event is contained within the entry-content of the hAtom entry, using the value-excerption-pattern to include the machine-data datetime. However, with full descendent parsing, the hAtom model will come out as the following: | ||
Line 51: | Line 65: | ||
Possible resolutions: | Possible resolutions: | ||
<div class="discussion"> | |||
* Specify the <code>mfo</code> (‘microformat object’) class be used when nesting microformats, as a processing instruction to parsers not to parse unrelated nested items | * Specify the <code>mfo</code> (‘microformat object’) class be used when nesting microformats, as a processing instruction to parsers not to parse unrelated nested items | ||
* Specify that <code>value</code> must only be read from <em>children</em>, not from <em>all descendants</em>. Restrictive, unlikely to work for existing hCard TEL usage. | * Specify that <code>value</code> must only be read from <em>children</em>, not from <em>all descendants</em>. Restrictive, unlikely to work for existing hCard TEL usage. | ||
* Specify the above (<q>parse <em>children</em>, not <em>all descendants</em>), but allow individual properties (such as <code>tel</code> to override and parse all descendants. This would result in a parse-depth flag on all fields, and many getting overridden for all descendants, but again, seems to be a well structured solution. Property name dictionaries in parsers would have to include the depth flag with the property. | * Specify the above (<q>parse <em>children</em>, not <em>all descendants</em>), but allow individual properties (such as <code>tel</code> to override and parse all descendants. This would result in a parse-depth flag on all fields, and many getting overridden for all descendants, but again, seems to be a well structured solution. Property name dictionaries in parsers would have to include the depth flag with the property. | ||
** This may break existing published microformats. [[User:TobyInk|TobyInk]] 07:25, 22 Jun 2008 (PDT) | |||
</div> | |||
===Parsing <code>title</code> from Empty <code>value</code> Elements=== | ===Parsing <code>title</code> from Empty <code>value</code> Elements=== | ||
Moved to: [[value-excerption-pattern-brainstorming#parsing_title_from_empty_value_elements|value-excerption-pattern-brainstorming]] | |||
===Parsing the value-excerption-pattern in combination with the ABBR-pattern=== | |||
<div class='discussion issues'> | |||
* | * How does <code><span class="country-name"><abbr class="value" title="Great">G</abbr> <span class="value">Britain</span></span></code> parse? | ||
** The main issue with this example is the lack of any explicit whitespace between the values. Under present parsing rules, this will parse as "GreatBritain". [[User:TobyInk|TobyInk]] 15:20, 6 Jul 2008 (PDT) | |||
</div> | |||
==Closed Issues== | ==Closed Issues== | ||
Line 81: | Line 96: | ||
* [[value-excerption-pattern]] | * [[value-excerption-pattern]] | ||
* [[value-excerption-pattern-brainstorming]] | |||
* [[value-excerption-dt-separation-test]] | |||
* [[value-excerption-value-title-test]] | |||
* [[machine-data]] | * [[machine-data]] |
Latest revision as of 16:34, 18 July 2020
This page documents issues with the value-class-pattern specification before 2016-06-20.
As the value class pattern is now a required feature of the microformats2-parsing specification:
Please add new issues to GitHub issues, prefixed with "vcp:"
See change control for how to move new issues forward.
Open Issues
These issues are awaiting resolution and reflection in the specification, but may not be blockers on the implementation of the specification.
Excluded Fields
- There seem to be some properties within which value excerpting is NOT allowed (or should not be allowed!) e.g. "type" in hCard. TobyInk 07:38, 22 May 2008 (PDT)
- You mean
type
as a sub-property oftel
? That's one of the identified machine-data items that needs a means of including the publisher's choice text along with the microformat specified one. Not to conflate two separate issues, but just noting that separation oftype
text andtype value
needs to be handled somewhere, and value-excerption-pattern could be considered as part of the solution. BenWard 07:54, 22 May 2008 (PDT) - Some fields make sense to exclude this, as it seems unintuitive, and can be used to avoid many of nested-microformat problems that may avoid a messier mfo pattern. E.g.
entry-summary
andentry-content
in hAtom, both could very feasibly have nested formats or any kind, but doesn't strike me as useful to segregate into "value" at all. BenWard 10:41, 6 Jun 2008 (PDT) - Total other alternative, make value-excerption opt-in. Would need a bit of effort to go through all the specs and clarify, but actually might make more sense. It's a useful pattern for some properties (especially those with data patterns). BenWard 10:41, 6 Jun 2008 (PDT)
- Setting the rules over depth-of-parsing (see below) to children-only would obviate the remaining need for this issue.
- You mean
White-space behavior when concatenating value nodes
- We specify that no characters get inserted between concatenated occurrences of ‘value’. Need to audit all properties to ensure that this behavior would be correct in all cases.
- Possibly specify that individual properties can override this behavior, specifying a separator character.
- Possibly specify that this should be a provision of parsing implementations, so as to maintain flexibility for future publishing.
Depth of Parsing
Currently any descendent is parsed, which causes issues if a microformat field using the value-excerption-pattern is nested within another.
Example:
<div class="hentry vevent"> <h1 class="entry-title summary">Party on Sunday!</h1> <div class="updated published">Tuesday <span class="value">2008-06-17</span></div> <p class="entry-content description">We're having a party on <span class="dtstart">Sunday, at 7pm! <span class="value">2008-06-22T19:00:00+0100</span></span>. Please bring your friends!</p> </div>
In this example, hAtom and hCalendar are interleaved. The DTSTART property of the event is contained within the entry-content of the hAtom entry, using the value-excerption-pattern to include the machine-data datetime. However, with full descendent parsing, the hAtom model will come out as the following:
ENTRY ENTRY-TITLE=Party on Sunday! UPDATED= 2008-06-17 PUBLISHED=2008-06-17 ENTRY-CONTENT=2008-06-22T19:00:00+0100
- e.g. an hCalendar
vevent
nested inside hAtomentry-content
must not result inentry-content
parsing as20080627T12:34:00+100
. - e.g. hCalendar defines
organizer
, which may be an hCard, which may have atel
property containing a sub-propertyvalue
. Under these parsing rules, the entireorganizer
field would be parsed as the telephone number.
- Cognition copes with this OK -- the organizer is parsed as a full contact with an hCard - not just a number. TobyInk 07:38, 22 May 2008 (PDT)
Possible resolutions:
- Specify the
mfo
(‘microformat object’) class be used when nesting microformats, as a processing instruction to parsers not to parse unrelated nested items - Specify that
value
must only be read from children, not from all descendants. Restrictive, unlikely to work for existing hCard TEL usage. - Specify the above (
parse children, not all descendants), but allow individual properties (such as
tel
to override and parse all descendants. This would result in a parse-depth flag on all fields, and many getting overridden for all descendants, but again, seems to be a well structured solution. Property name dictionaries in parsers would have to include the depth flag with the property.- This may break existing published microformats. TobyInk 07:25, 22 Jun 2008 (PDT)
Parsing title
from Empty value
Elements
Moved to: value-excerption-pattern-brainstorming
Parsing the value-excerption-pattern in combination with the ABBR-pattern
- How does
<span class="country-name"><abbr class="value" title="Great">G</abbr> <span class="value">Britain</span></span>
parse?- The main issue with this example is the lack of any explicit whitespace between the values. Under present parsing rules, this will parse as "GreatBritain". TobyInk 15:20, 6 Jul 2008 (PDT)
Closed Issues
These issues are closed, and either dismissed with reason, or the specification has been updated in resolution.
Nested value
Should <span class="value">Foo <span class="value">Bar</span></span>
parse as foo bar
or bar
? Should value
elements be allowed to be nested within value
elements?
Resolution: Disallowed. Deemed complex to parse, and unnecessary when publishing.