On 6/9/2011 3:54 AM, stuart yeates wrote:
> On 09/06/11 06:11, Brett Zamir wrote:
>> Hello Stuart,
>> On 6/7/2011 4:36 AM, stuart yeates wrote:
>>> A couple of points:
>>> * Given that TEI is significantly more expressive than HTML5, any
>>> serialization would be lossly, and my understanding of the genetic
>>> editing proposal is that this makes TEI even more expressive.
>> Although it is more expressive semantically than the default HTML5
>> semantics, HTML5 Microdata allows for preservation of every single
>> semantic feature of TEI (literally allowing use of the TEI namespace on
>> the "itemtype" attribute and all of the TEI element and attributes
>> (e.g., by markup including anonymous divs or spans with the "itemprop"
>> attribute or in-body <meta/> and <link/> elements), though I think we
>> ought to narrow it down and determine a specific single algorithm).
>> So, technically, since it can subsume it, HTML5 can more expressive than
>> TEI (of course, if your TEI embeds XHTML, then it's an even, if still
>> meaningless, battle).
> Yes, you can technically encode TEI tags as HTML5 Microdata.
> However, if you do thing for TEI standoff markup (for example) you end
> up with something that is HTML only technically and breaks all of the
> assumptions every system, programmer and user has about HTML.
Why? Most HTML programmers may be new to HTML5, but once they understand
the handful of properties like "itemprop", they don't need to even know
anything about the semantics of TEI (though the itemtype "namespace"
points them to the TEI site if they cared about semantics). I'm a web
app programmer myself and find absolutely nothing disruptive about the
serialization besides finally providing a uniform
search-engine-friendly, text-editor-friendly format.
As far as stand-off markup, XInclude is not supported by default in
browsers, if that's what you mean, though it is not difficult to add
such support. If you mean use of <ptr/> there is no difference between
TEI and using <link/> in HTML. Yes, tools have to be developed to
support XPointers, but that's something the web actually needs to learn
from TEI. But there is absolutely no inherent difference between whether
TEI uses it or X/HTML uses it, except that tools might need to be
developed for HTML if they are currently only available in TEI. And
again, one can convert back to TEI if that is needed.
Maybe if you can give specific examples, I can either see your point or
offer examples of how they could be addressed.
> Calling it HTLM5 seems of, at best, marginal benefit and
Why are Google, Microsoft, and Yahoo all endorsing embedding of
semantics from other semantic vocabularies as per http://schema.org ?
Why shouldn't a Google searcher be able to specify--without Google
needing to program specifically for TEI--that one wishes to find all TEI
quotations attributed to a certain person? Why does there have to be a
fracture between web and TEI?
> displaying such content to users is, I believe harder not easier in
> such a format.
With a stylesheet converting from TEI, there is nothing harder besides
the step needed to convert (which could itself be automated). I will
admit it is a little more cumbersome to create and if I were responsible
for a TEI project I certainly wouldn't choose it as the main language of
markup, but the point is to design stylesheets that can convert
losslessly in both directions.
>>> * The TEI community and the digital humanities community more
>>> generally are pretty closely tied to the concept of the book, so I
>>> suggest targeting the flavour of HTML5 as used in ePubs.
>> Do you have an online reference elaborating on an ePub HTML5 flavor? As
>> far as I can see, ePub is not an HTML format.
> ePub is a zip file of HTML + media files + some standardised metadata
> files (including DAISY). See http://en.wikipedia.org/wiki/EPUB