Using the Standard Document as a Reference (and difficulties therein)
Ted Han <[email protected]> Tue, 9 Feb 2010 08:12:39 -0500
| Newsgroups | gmane.comp.web.smil |
|---|---|
| Message-ID | <[email protected]> |
--000e0cd2435a1a7914047f2aacbf Content-Type: text/plain; charset=ISO-8859-1 Hey Folks, I have sunk myself into the endeavor of trying to produce summaries of the standard (for my own use, and for others). My goal is to produce these summaries programmatically from the standards document itself, given that it's validating HTML, and the normative reference. I've been able to interrogate the document for some information, but i am dismayed to find that the large bulk of the useful information that one could glean from the document, is unextractable, due to semantic inconsistencies in the standard's markup. My immediate goal is to produce a quick reference for SMIL elements and their applicable attributes (again directly from the Standard). I am aware that the SMIL 3.0 reference book has attribute references for all the elements, but, unfortunately, as a book, it's awfully difficult to share and/or search the content therein, and casual users of SMIL may not be interested in purchasing the reference (nor does purchasing books travel at the speed of the internet). At this point, i'm some what resigned to the fact that it will be impossible to pull all of the vital information from the current standard programmatically (although if anyone has suggestions i would be very interested in hearing them), but i still think it is worthwhile to point out the inconsistencies, so that they might be rectified in future versions of the Standard. That said, i don't know what the likelihood, such changes would be adopted, or by what process such changes should be offered. If anyone could clue me in i'd be quite grateful. Any generally help or suggestions would be greatly appreciated! -Ted To provide some examples, (disregarding typos in normative sections of the document, like Table 1 of section 2.4), there's a variety of inconsistencies between how element and attribute definitions are marked up. Depending on the section, attributes may or may not be contained within a dl or div with the class "adef-list" or "attdef-list" applied. Element definitions are labeled with the "edef" class, but unfortunately, all of the table of contents links to these sections are also inexplicably labeled with the "edef" class. Additionally, none of these elements, attributes or lists are contained with in divs that indicate what section they belong to, so one must take the leap of faith that the preceding h2 element accurately indicates the section to which the element(s) or attribute(s) belongs. --000e0cd2435a1a7914047f2aacbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Folks,<div><br></div><div>I have sunk myself into the endeavor of tryin= g to produce summaries of the standard (for my own use, and for others). = =A0My goal is to produce these summaries programmatically from the standard= s document itself, given that it's validating HTML, and the normative r= eference. =A0I've been able to interrogate the document for some inform= ation, but i am dismayed to find that the large bulk of the useful informat= ion that one could glean from the document, is unextractable, due to semant= ic inconsistencies in the standard's markup.</div> <div><br></div><div>My immediate goal is to produce a quick reference for S= MIL elements and their applicable attributes (again directly from the Stand= ard). =A0I am aware that the SMIL 3.0 reference book has attribute referenc= es for all the elements, but, unfortunately, as a book, it's awfully di= fficult to share and/or search the content therein, and casual users of SMI= L may not be interested in purchasing the reference (nor does purchasing bo= oks travel at the speed of the internet).</div> <div><br></div><div>At this point, i'm some what resigned to the fact t= hat it will be impossible to pull all of the vital information from the cur= rent standard programmatically (although if anyone has suggestions i would = be very interested in hearing them), but i still think it is worthwhile to = point out the inconsistencies, so that they might be rectified in future ve= rsions of the Standard. =A0That said, i don't know what the likelihood,= such changes would be adopted, or by what process such changes should be o= ffered. =A0If anyone could clue me in i'd be quite grateful.</div> <div><br></div><div>Any generally help or suggestions would be greatly appr= eciated!</div><div><br></div><div>-Ted</div><div><br></div><div>To provide = some examples, (disregarding typos in normative sections of the document, l= ike Table 1 of section 2.4), there's a variety of inconsistencies betwe= en how element and attribute definitions are marked up. =A0Depending on the= section, attributes may or may not be contained within a dl or div with th= e class "adef-list" or "attdef-list" applied. =A0Elemen= t definitions are labeled with the "edef" class, but unfortunatel= y, all of the table of contents links to these sections are also inexplicab= ly labeled with the "edef" class. =A0Additionally, none of these = elements, attributes or lists are contained with in divs that indicate what= section they belong to, so one must take the leap of faith that the preced= ing h2 element accurately indicates the section to which the element(s) or = attribute(s) belongs.</div> --000e0cd2435a1a7914047f2aacbf--