Re: [whatwg] Bibliography Markup in HTML5
On Mon, Oct 5, 2009 at 7:51 PM, Ian Hickson wrote: > On Sun, 27 Sep 2009, tjeddo wrote: >> >> I am surprised at how little concern there seems to be over the lack of >> bibliography markup in HTML5. > > There's a lot of concern, but it was deemed that microdata is a better way > of addressing this than specific elements. Thanks for your response. After reviewing the info on microdata, I certainly agree that microdata would be a great fit for marking up bibliographies and their entries. I do hope that a controlled vocabulary is worked out and gets widely adopted... but I recall this issue was already discussed at length. >> What if HTML5 specified this approach--except that in place of the >> (definition list) tags, a collection of entries would be contained >> between tags? That is, the above example would look as >> follows: >> >> ... >> >> [RFC5322] >> http://www.ietf.org/rfc/rfc5322.txt";>Internet Message >> Format, P. Resnick. IETF, October 2008. >> >> ... >> >> >> The value here is the elimination of ambiguity > > What ambiguity? In my example scheme, a parsing program that encounters a section would be able to determine (by context) that the dt and dd elements encountered within represent bibliography entries. Just like a parsing program that encounters a section can determine that a dt element contains the caption for the figure. However, if dt and dd are encountered simply within a dl element; then no additional semantic information can be determined. It would have been more appropriate if I said that ambiguity is reduced in my example scheme (not eliminated). >> and that a number of new inferences can now be drawn by user agents. >> With the tags, the interpreting agent can only determine that there >> is a definition list containing term/definition entries. Whereas, in >> the context of a new bibliography section element, user agents can >> unambiguously interpret the 'dt' element to be the displayed content >> that humans identify a bibliography entry by (e.g., "[RFC5322]" in the >> example given). > > Why is this valuable? How do you expect browser vendors to change their > interface to use this? > > Why would it not be better to have a microdata vocabulary for this? In my understanding, microdata certainly seems like a sufficient way to handle bibliography entries--once again, hoping that a standardized vocabulary develops. The scheme I discussed about introducing a 'bibliography' element and reusing the 'dt' and 'dd' elements within, I simply felt was consistent with the introduction of other new HTML5 elements describing the pieces of a virtual document (e.g., article, section, figure, aside, etc.). Additionally, the scheme consistently reused the elements 'dt' and 'dd' in the 'bibliography' context just as they are reused in the new 'figure' and 'details' context. Although, I have to admit I'm not sure I'm a fan of this element overloading as opposed to introducing explicit tags to cover these concepts when appropriate. But I do understand that HTML5 is constrained by legacy HTML and also that microdata is another way to work around these constraints. I'm not arguing that microdata isn't the best approach here; but it should be considered that first class elements are more legible than microdata. And I'm sure this is why many of the new HTML5 elements are not implemented as microdata. I'm just raising ideas here. Regards, Tim Eddo
Re: [whatwg] Bibliography Markup in HTML5
On Sun, 27 Sep 2009, tjeddo wrote: > > I am surprised at how little concern there seems to be over the lack of > bibliography markup in HTML5. There's a lot of concern, but it was deemed that microdata is a better way of addressing this than specific elements. > What if HTML5 specified this approach--except that in place of the > (definition list) tags, a collection of entries would be contained > between tags? That is, the above example would look as > follows: > > ... > > [RFC5322] > http://www.ietf.org/rfc/rfc5322.txt";>Internet Message > Format, P. Resnick. IETF, October 2008. > > ... > > > The value here is the elimination of ambiguity What ambiguity? > and that a number of new inferences can now be drawn by user agents. > With the tags, the interpreting agent can only determine that there > is a definition list containing term/definition entries. Whereas, in > the context of a new bibliography section element, user agents can > unambiguously interpret the 'dt' element to be the displayed content > that humans identify a bibliography entry by (e.g., "[RFC5322]" in the > example given). Why is this valuable? How do you expect browser vendors to change their interface to use this? Why would it not be better to have a microdata vocabulary for this? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Bibliography Markup in HTML5
Erik, Thanks for your response. >> I mean, there is new language support >> for an 'aside' section element but no 'bibliography' section element!? > > A full-on bibliography (if it's not a separate page) would function > well as a or , unless I misunderstand the way those > elements are supposed to work. Footnotes certainly make sense within a footer. Although, like you state, a full-on bibliography might be its own page but doesn't intuitively belong within a footer--at least in the conventional sense of the word. I guess that is what disturbs me about what is written in Section 4.4.9 on the Footer element. "When the footer element contains entire sections, they represent appendices, indexes, long colophons, verbose license agreements, and other such content. The footer element is not sectioning content; it doesn't introduce a new section." Bibliographies and appendices are often one or more traditional page lengths, which is why I don't think the footer element makes sense here. Although, I would be very curious to hear the author's intentions for putting appendices, indexes, etc. in a footer. In any case it does seem like the term 'footer' is being overloaded here. I think a formal bibliography fits more appropriately within a as opposed to a . Although, I think the value of the scheme I brought up in my original email would be lost. That is, a user agent could expect bibliography entries within the context of tags, but not so if simply in the context of tags. >> ... >> [RFC5322] >> http://www.ietf.org/rfc/rfc5322.txt";>Internet Message >> Format, P. Resnick. IETF, October 2008. >> ... >> > 1. There'd need to be some clear-cut understanding about what would go > in the and elements. Would the before the "citation > entry" and the optional for "annotation" or something? Would > multiple s be allowed per ? Would authors understand the > difference? In your example, it feels like is for "shorthand > bibliographic entry" and is for "longer bibliographic entry," > which feels a bit cumbersome and offers pretty good odds for repeated > content. I agree. Explicit interpretations for the and tags would need to be provided if present between tags--but this is no different than their contextual definitions given for the new figure and details elements. In the bibliography context some attempted definitions might be ... The 'dt' element's content is a displayed sequence of characters that a reader uses to associate a citation in the main document content to the bibliography entry identified by the sequence. Content examples for from various citation styles could be: "[SVG], [13], 13.,..." or the 'dt' element may be empty (in the case of MLA style) and simply provide an 'id' attribute that can be linked to in citations. The 'dt' and 'dd' would occur in pairs. The 'dt' is the shorthand reference key that corresponds to the bibliography entry details of the following 'dd' element. > which feels a bit cumbersome and offers pretty good odds for repeated > content. I think the redundency is necessary as a citation within the text will not always be exactly the same as the key provided in the 'dt' element of the intended bibliography entry. An example citation might look like: "...it is proven that foo has only three bars [ABC, pp. 23--24]." where the corresponding bibliography 'dt' element would look like this: [ABC] ...entry details for ABC... That is, specific pages are provided after the key--yet it is still clear the author is referring the the [ABC] bibliography entry. > 2. I'm not sure the pattern allows for any useful mnemonic > device related to a dedicated element. You are right. Although, this is exactly what is being done in the new 'figure' and 'details' elements. From Section 4.8.1 "The first dt element child of the element, if any, represents the caption of the figure element's contents. If there is no child dt element, then there is no caption." Certainly a new 'caption' element would have been ideal to represent the caption of a figure. But unfortunately, HTML5 is trying to reuse existing tags where appropriate to support legacy HTML. While 'dt' and 'dd' are generic, you can arguably convince yourself that the content of 'dt' is the term or item being defined by or mapped to the 'dd' definition description. In summary, it is the W3C's use of and for marking up their bibliography entries in their specifications that I thought made the most sense in the absence of a more comprehensive bibliography vocabulary. And placing these elements in a new context such as allows you to provide specific contextual definitions. Additionally, user agents can unambiguously interpret the contents of the 'dt' and 'dd' elements if they encounter them within tags as opposed to or tags. -- Tim Eddo
Re: [whatwg] Bibliography Markup in HTML5
On Sun, Sep 27, 2009 at 8:28 PM, tjeddo wrote: > I am surprised at how little concern there seems to be over the lack of > bibliography markup in HTML5. Most of this discussion has revolved around the element as well as methods to mark-up attribution in such elements as . There's also been some discussion about Bibtex as microdata, though I think that's been dropped. > I mean, there is new language support > for an 'aside' section element but no 'bibliography' section element!? A full-on bibliography (if it's not a separate page) would function well as a or , unless I misunderstand the way those elements are supposed to work. > ... > [RFC5322] > http://www.ietf.org/rfc/rfc5322.txt";>Internet Message > Format, P. Resnick. IETF, October 2008. > ... > > > The value here is the elimination of ambiguity and that a number of new > inferences can now be drawn by user agents. With the tags, the > interpreting agent can only determine that there is a definition list > containing term/definition entries. Whereas, in the context of a > new bibliography section element, user agents can unambiguously interpret > the 'dt' element to be the displayed content that humans identify a > bibliography entry by (e.g., "[RFC5322]" in the example given). > Additionally, in this context the 'dd' element would be defined to contain > "a representation of a bibliography entry." Of course, more concise > definitions for these elements occurring in the bibliography context should > be worked out. 1. There'd need to be some clear-cut understanding about what would go in the and elements. Would the before the "citation entry" and the optional for "annotation" or something? Would multiple s be allowed per ? Would authors understand the difference? In your example, it feels like is for "shorthand bibliographic entry" and is for "longer bibliographic entry," which feels a bit cumbersome and offers pretty good odds for repeated content. 2. I'm not sure the pattern allows for any useful mnemonic device related to a dedicated element. My own practice has been to mark-up a bibliography as either a or within a div, with each being used to mark discrete items in the list of works cited. Would a more generalized block/inline element to identify "attribution" (such as or my own attempt to expand the function of ) suit your needs? Erik Vorhes
[whatwg] Bibliography Markup in HTML5
I am surprised at how little concern there seems to be over the lack of bibliography markup in HTML5. I mean, there is new language support for an 'aside' section element but no 'bibliography' section element!? Certainly a section element standardization intended to reinforce the integrity of an author's published content deserves a little more priority over support for standardizing aside sections (no disrespect for 'aside's being a worthy language addition). Now I am not arguing for the addition of a comprehensive bibliography vocabulary as discussed in the topic of 'on-bibtex-in-HTML5'; although, I hope in the long run that this might happen. What I am asking is that a lower-precision, pragmatic bibliography specification be considered for inclusion in HTML5. What follows is one approach for providing initial bibliography standardization in HTML. I feel it may be low cost to implement, is consistent with new additions to HTML5, and won't restrict extensibility in the future towards a more comprehensive bibliography specification. When looking at approaches for marking up bibliography entries I came across the bibliographies in the HTML5 draft specification as well as the other W3C specifications that seemed to use the same markup approach. Here is an example bibliography entry from the HTML5 draft specification: ... [RFC5322] http://www.ietf.org/rfc/rfc5322.txt";>Internet Message Format, P. Resnick. IETF, October 2008. ... Citing this entry in the main text from the same page is simply done using an anchor element that links to the 'id' attribute of the 'dt' element: [RFC5322] or, for example, if citing content on a specific page is to be specified [RFC5322, p. 5]. Note, If the author preferred, say, the MLA style, then they would just change the displayed square brackets to parenthesis and omit the ", p. ". Where am I going with this? What if HTML5 specified this approach--except that in place of the (definition list) tags, a collection of entries would be contained between tags? That is, the above example would look as follows: ... [RFC5322] http://www.ietf.org/rfc/rfc5322.txt";>Internet Message Format, P. Resnick. IETF, October 2008. ... The value here is the elimination of ambiguity and that a number of new inferences can now be drawn by user agents. With the tags, the interpreting agent can only determine that there is a definition list containing term/definition entries. Whereas, in the context of a new bibliography section element, user agents can unambiguously interpret the 'dt' element to be the displayed content that humans identify a bibliography entry by (e.g., "[RFC5322]" in the example given). Additionally, in this context the 'dd' element would be defined to contain "a representation of a bibliography entry." Of course, more concise definitions for these elements occurring in the bibliography context should be worked out. The specification should not dictate the bibliography style or encoding used within the 'dd' element--just that it contains a representation of a bibliography entry. This specification shouldn't restrict a more semantically structured encoding of the bibliography entry should a standardized approach emerge in the future--or an author choose to use their own homegrown structured encoding and style. I believe this one simple addition and specification of definitions would open up a number of new possibilities for those who work with bibliographies. Here are some of the pros of this approach: * Reuses the 'dt' and 'dd' elements consistent with their reuse in the new 'figure' and 'details' contexts. That is, how you interpret the content of the 'dt' and 'dd' elements is dependent on the context they occur in. * bibliography appropriately fits in with the new list of section elements: article, heading, footer, section, nav, aside, bibliography * Does not constrain a more comprehensive and concise bibliography vocabulary that may be worked out in the future. Additionally, authors can provide their own structured elements and CSS style to represent a bibliography element. * Clear specification for marking up bibliographies would encourage more Web authors to provide them. Standardized HTML markup for supporting published claims might cause more readers to critically evaluate the claims expressed in an author's writing when no sources are provided. This in turn might encourage the more honest authors to provide bibliographies. * Enables the possibility of support tools that traverse the Web to link arguments with evidence encoded within HTML. Supports researchers. If you made it this far reading, I appreciate your concern for this topic. Please provide any constructive criticism, revisions, alternatives, or general thoughts on this approach or the topic of bibliographies in HTML5. Regards, Tim Eddo
