[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] (corrected) RE: When you create a markup language, what do yourparent el
(Resend with correction ...doh) 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?, genus?, species? } quantity = element quantity { being, categories?, subcategory?, genus?, species? } quality = element quality { being, categories?, subcategory?, genus?, species?} relatives = element relatives { being, categories?, subcategory?, genus?, species? } somewhere = element somewhere { being, categories?, subcategory?, genus?, species? } sometime = element sometime { being, categories?, subcategory?, genus?, species? } position = element position { being, categories?, subcategory?, genus?, species? } having = element having { being, categories?, species, subcategory?, genus?, species? } acting = element acting { being, categories?, species, subcategory?, genus?, species? } acted_upon = element acted_upon { being, categories?, subcategory?, genus?, species? } ;; ======================================================================================= (You would want a linking structure as well as just element containment.) E.g., <substance genus="dog"> <having genus="limbs"> <quantity subcategory="number" genus="count">4</quantity> <substance genus="legs" /> <having genus="feet"> <quantity subcategory="number" genus="count">1</quantity> <substance genus="foot" species="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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|