Print

Print


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,