OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Approaches to Expanding the Semantics of a Community'sSelf-Interested XML Vocabulary


I'll put the idealistic option 3 aside right away ;-)

Regarding options 1 and 2, I think it is valuable to look at both of 
them as translations. The only difference is that option 1 does not keep 
the original content ("destructive translation"), while option 2 keeps 
the original content via mixed vocabularies ("non-destructive translation").

What I like about option 2 is that it is practical in the sense that it 
solves the communication issue between vocabulary experts and 
programmers, who are usually different people. I think this 
accessibility to content/vocabulary experts is what will make Option 2 
eventually successful.

Let me explain my humble theory:

Human content editors most likely know about editing XML and have 
knowledge about one or more different vocabularies, but may not know 
XSLT or translation programming. But, using mixed vocabularies, content 
editors can easily publish content in both vocabularies without having 
to edit two documents and providing two URLs, and they don't need to 
explain the 'mapping' to developers they may not even know (assuming we 
are on the wild Web, not in a specific organization with all the skills 
required, clear roles and processes to develop translations).

 From then on, by looking at the examples published on the Web by by 
content editors, programmers can take over, extracting mapping patterns 
and automating the tedious work of generating mark up for same content 
in different vocabularies. Probably by then, most content consumers may 
have observed that the mixed vocabulary approach is more common than the 
single vocabulary approach and will have accepted the idea of ignoring 
whatever tags from a vocabulary they don't understand, instead of 
rejecting them as schema invalid. For those consuming clients that 
really can't handle mixed vocabularies, server-side filtering requested 
via a URL parameter is easy for both manually edited and 
programmatically generated mixed vocabulary content.

So, the focus on content experts is what I believe will make Option 2 
eventually successful. It is my understanding that the microformats.org 
community has followed this model of focusing on human content editors, 
and enjoyed spontaneous adoption and success this way.

Over time, some tags in different vocabulary never get used and some get 
used a lot, and assuming the content is published on the Web, we can 
track usage statistics (http://code.google.com/webstats/). Eventually, 
based on these statistics every vocabulary editor incorporates the most 
widely used tags from other vocabularies and we reach organically and 
chaotically the goal of a single vocabulary, at least for the most 
common concepts.

That said, from an implementation standpoint, for option 2, I think I'd 
prefer a pure XML or pure HTML implementation instead of the one you 

Pure XML-based mixed vocabulary approach, which allows multiple namespaces:

<?xml version="1.0" encoding="UTF-8"?>
<v:vcard xmlns="http://www.firstcommunity.org"; xmlns:v="http://www.ietf.org/vcard";><Point-of-Contact>
    <v:fn><Name>John Smith</Name></v:fn>
        <v:street-address><Street>10 Tremont St.</Street></v:street-address>

Pure plain old semantic HTML-based mixed vocabulary approach, which 
assumes a single namespace:

<?xml version="1.0" encoding="UTF-8"?>
<div class="Point-of-Contact vcard">
   <span class="Name fn">John Smith</span>
   <span class="Address adr">
      <span class="Street street-address">10 Tremont St.</span>
      <span class="City locality">Boston</span>
      <span class="State region">MA</span>
   <span class="Telephone tel">617-123-4567</span>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS