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&#39;s validating HTML, and the normative r=
eference. =A0I&#39;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&#39;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&#39;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&#39;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&#39;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&#39;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&#39;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 &quot;adef-list&quot; or &quot;attdef-list&quot; applied. =A0Elemen=
t definitions are labeled with the &quot;edef&quot; class, but unfortunatel=
y, all of the table of contents links to these sections are also inexplicab=
ly labeled with the &quot;edef&quot; 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--