Language Maps [was RE: [uf-discuss] Microformats vs XML]

Tue May 2 00:33:52 PDT 2006

Before honoring Tantek's suggestion to move this to the "Bad Topics" list, I
hope I can clarify some misunderstanding and admit a few mistakes on my
part.

Part of this exploration is well grounded in a current engineering problem
I'm engaged in. Despite attestations that what I'm talking about is a hard
problem, and much bigger than microformats, it isn't.  If you think it is,
then I have failed to communicate clearly.

Of course, that doesn't change the fact that I'm just getting into the zen
of microformats. As I learn, it is natural to say "Why can't we do XX?",
especially when XX fits with the real-world problems I'm addressing right in
front of me.  As has been pointed out, some of my examples were bad XHTML.
Once or twice that was from irrelevant syntactical typos, a few times, the
errors were not so irrelevant. 

I have to say that my understanding of the limits of XHTML has increased
dramatically as I poured over the XML, XHTML, XMDP, GRDDL, and XSLT specs.
Arbitrarily adding a microformat attribute doesn't really work and there are
some current provisions for identifying languages that I hadn't been aware
of.  And my appreciation for how Microformats fits into those limitations
has greatly increased.

That said, I believe this can be cast as a tractable problem and that
microformats is in a stage where we can actually keep the door open to a
solution rather than locking down a spec that precludes it.

I had argued for a strong link to a profile and then suggested a specific
use for that profile.  However, given that we really only have the DIV and
SPAN tags to work with and they really only have the class attribute
available for what we are talking about, I don't think there is a good way
to link a given element to a profile, which makes moot much of my commentary
about UID specifiers on a per element basis.  Documents can link to a
profile in the <HEAD>, but I was hoping for something more granular. Oh
well. Not much I can do about that.

The idea of mapping between languages however is not as crazy or hard as
some of you think.  

Michael MD [mdagn at spraci.com] wrote:
> This translation could be a 
> relatively simple server-side XSLT.  But expecting every parser to 
> translate every document before parsing it would require a distributed 
> translation system accessible by any programming language.  If we had 
> that, I expect we'd find better uses for it.

The first sentence is correct.  The latter two, I would say, less so.  After
further research, it looks like GRDDL [1] and XSLT [2] enable the type of
transformation I'm talking about.

[1] http://www.idealliance.org/proceedings/xtech05/papers/03-06-01/ 
[2] http://www.w3.org/TR/2001/REC-xsl-20011015/ 

At the end of the day, I am not talking about a translation in the
linguistic sense of the word, rather it is a transformation from one
namespace where the signifiers are in some other language to another
namespace where the signifiers are in English.  The point being that once a
single developer specifies the transformation, anyone can use it, enabling a
grass roots semantic rewrite of the web using native language microformats
in countries where English is more of a barrier than an enabler.  This
approach would make that non-English data parseable by any system which
understand the base namespace and can apply the specified transformation.
And because the spec is still based on the underlying microformat standard,
the underlying meaning hasn't changed, merely the signifiers used in any
particular transformation.

There is still the linguistic issue of making use of the content of such
international presentations, but at least for hCard and hCalendar, these
issues are fairly constrained. And frankly, knowing that a particular phrase
is, say, French for a location makes the translation a bit simpler. And that
is precisely what the microformat already allows.

GRDDL suggests the following mechanism to link such a transformation in
XHTML:

==
For XHTML, given the syntactic constraints imposed by the required DTD
validity, adding an attribute in the html root element is not an option.
Thus, GRDDL proposes to use a specific rel attribute value (transformation),
anchored in URI space through a defined profile attribute value:

GRDDL link in an XHTML document
<html xmlns="http://www.w3.org/1999/xhtml">
  <head profile="http://www.w3.org/2003/g/data-view">
    <title>Some Document</title>
    <link rel="transformation"
       href="http://www.w3.org/2000/06/dc-extract/dc-extract.xsl" />
==

GRDDL is still pre-standard, but if it works and is compliant with other
standards, why wouldn't we support it for this type of transformation?

With that, I'm happy to honor the social dictate voiced by Tantek. I'm new
here and still figuring things out.  However, if my work proves fruitful, I
will be happy to share it with you once I have something I can demonstrate
in the way of standards-compliant working code.

Cheers, 

-j

--
Joe Andrieu
joe at andrieu.net
+1 (805) 705-8651