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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] +1 (805) 705-8651 _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
