Hello!
Thanks for this suggestion!
> Comments?
I would like to write three suggestions (in order of increasing
radicality) about the suggested "embeddedHtml" element. I would prefer the
third suggestion, but if you do not like it, the first two ones may be
useful.
The first of my suggestions aims at syntactically reducing risks for
confusion through a modification of the element name from "embeddedHtml"
to "embeddedHtmlSnippet" (or similar) because the HTML code present inside
it is NOT an entire and valid HTML serialization.
The second one concerns semantic (foreward-)compatibility. As of today,
there are several (X)HTML versions and (probably) more are to come in the
future. Therefore, I suggest to add an attribute (for example
@contentVersion) on the "embeddedHtmlSnippet" element. Furthermore, I
would suggest that the value of this attribute would match the value of
the @version attribute on the (X)HTML element when applicable (for example
version="XHTML+RDFa 1.0") or otherwise to be defined in accordance with
some (more or less formal) standard for that, for example
@contentVersion="HTML 4.01 Transitional" (in analogy with doctype="HTML
4.01 Transitional" in the w3c validator API).
My third suggestion is a bit more radical: Noting that the only
semantically relevant information provided by the content of the
"embeddedHtml" element in the example provided in the e-mail I attempt to
answer, I would suggest NOT to add an embeddedHtml element and instead add
a "linkText" element under the "licenseDocumentationIdentifier" element
(alternatively, as a @linkText attribute on the "licenseTerms" element or
on the "licenseDocumentationIdentifier" element). Thus, we would avoid to
bind ourselves to (X)HTML and the information within the linkText (element
or attribute) would be easily useful even when the source is to be
processed towards an other output format containing hypertext - either an
other XML subformat such as SVG or a non-XML format such as groff or pdf.
I consider that this would improve both scalability, portability and
forward-compatibility.
Using an element in my third suggestion would also make it possible to
provide several "linkText" elements, for example combined with different
attributes. One example could be an @xml:lang attribute to provide a
link-text in different languages or a @textLength attribute such as
textLength="short" and textLength="long" making it easier for rendering
applications to render different link-texts depending on the place
available for that - for example, the value of the "long" linkText could
be used within plain text, whereas the value of the "short" linkText could
be used in tables. Such a @linkLength attribute would be friendly for
application because they would not need to fetch all "linkText" elements
and compare the length of their contents (assuming that the value of the
@linkLength attribute is reliable, of course).
Comments are of course welcome!
Regards!
SaaĊĦha,
|