Re: [xml-dev] RE: When you create a markup language, what do yourparent

[rjelliffe <rjelliffe@allette.com.au>]

 On Mon, 26 Sep 2011 18:49:39 -0400, "Costello, Roger L." 
 <costello@mitre.org> wrote:
 ...
> Are those the only markup languages that have a consistent definition
> of what parent elements and child elements mean?

 The automated dump formats for relation tables would also have 
 "consistent" definitions, in the sense you use: simple rules independent 
 of element names, but determined by patterns.
 
> If one is creating a markup language and wants to adopt a consistent
> definition for parent elements and child elements, is resource/object
> and property/attribute the only way to accomplish it?

 I think this comes down to a question of what the fundamental 
 categories your analysis requires.

 For example, if you were marking up statements, and you were being 
 rigorous and generic/obsessive about it, you might go back to 
 Aristotle's Categories (or pick your favorite Scholastic or category 
 system). There is a good intro at 
 http://plato.stanford.edu/entries/aristotle-categories/#TenFolDiv

 You might then make a markup meta-language where the GIs were based on 
 the ten categories:

 ;; 
 =======================================================================================
 categories =  substance | quantity | quality
          | relatives | somewhere | sometime | position | having | 
 acting | acted_upon | text

 subcategory = attribute subcategory { text }

 being = attribute being { "accidental universal" | "essential 
 universal" | "accidental particulars" | "non-accidental particular" )}

 species = attribute species { text }

 genus = attribute genus { text }

 substance 	= element substance { being, categories?, subcategory?, 
 species, genus? }
 quantity	 = element quantity { being,  categories?, subcategory?,  
 species, genus? }
 quality 	= element quality { being,   categories?, subcategory?,  
 species, genus? }
 relatives 	= element relatives { being, categories?, subcategory?,  
 species, genus?  }
 somewhere 	= element somewhere { being, categories?, subcategory?,  
 species, genus?  }
 sometime 	= element sometime { being, categories?, subcategory?,  
 species, genus?  }
 position 	= element position { being, categories?, subcategory?,  
 species, genus?  }
 having 	= element having { being, categories?, species, subcategory?,  
 genus?  }
 acting 	= element acting { being, categories?, species, subcategory?,  
 genus?  }
 acted_upon 	= element acted_upon { being, categories?, subcategory?,  
 species, genus?  }

 ;; 
 =======================================================================================

 (You would want a linking structure as well as just element 
 containment.)

 E.g.,

 <substance species="dog">
   <having species="limbs">
      <quantity subcategory="number" species="count">4</quantity>
      <substance species="legs" />
      <having species="feet">
         <quantity subcategory="number" species="count">1</quantity>
         <substance species="foot"  genus="paw" />
       </having>
   </having>


 Using such categories is not entirely fanciful: I found that writing 
 schemas in terms of categories was very useful for *communicating 
 meaning to developers* who did not have English as their first language, 
 on a project where the element names used by previous schema developers 
 were not particularly clear: I wrote up the actual approach I used as 
 "highly generic schemas":
   http://broadcast.oreilly.com/2010/07/highly-generic-schemas.html

 In fact, you could take many existing schemas and rotate their element 
 name into the species or genus attributes, fulling in the gaps by hand. 
 Or, more usefully, you can convert from markup such as above into 
 conventional schemas quite readily.

 Indeed, that is pretty much what I think many programmers do in effect 
 when processing the XML: they get a mental model of what categories each 
 element belongs to. (This might explain RDF's lack of take up by 
 developers as well: it certain can be used to encode the kind of 
 Aristotlean categories as above, but it does not ensure that the 
 categories are explicit or always present: the programmer does not 
 necessarily have less mental work to do to catgorize information nor to 
 fill in gaps.  You can imagine that a GRDDL transform for this kind of 
 document would not be hard.)

 My point is not to suggest that Aristotle was right. I would not dare 
 to say that we are not smarter than Aristotle!  :-)   Merely I am 
 responding to Roger's question to say that RDF or simple "is-a" and 
 "has-a" relationships are not the only games in town. Categories such as 
 Aristotle's provide concepts which are less atomic than RDF but more 
 systematic than conventional schemas: they may be a sweet spot for some 
 cases, or at least a good design inspiration.

> Is an Object-Oriented approach to markup the only viable approach
> when one wants to have a consistent definition for parent elements 
> and
> child elements? That would be quite astonishing, given that people
> such as Tim Bray argue that "XML is 180 degrees apart from OO".

 I think Tim is referring to the kind definition of Objects as 
 programming structures which encapsulate both data and methods. XML is 
 based on the separation of processing from data, notwithstanding that as 
 a pure syntax you can represent methods using it (e.g. XSLT) and that 
 you can have a representation of XML data as Objects with very generic 
 (non-semantic/type-specific) operations defined (e.g. DOM).

 Cheers
 Rick