Re: Data Interoperability ... Why do some XML vocabularies sp
At 2010-08-18 15:13 -0400, Costello, Roger L. wrote: >I see two kinds of XML vocabularies: > >1. Those containing markup that has been assigned both meaning and behavior. > >2. Those containing markup that has been assigned only meaning. I boil that down to one kind of XML vocabulary: a set of labels associated with bits of content. What you do with what is at the label is up to you ... it isn't up to the vocabulary. XML is for the interchange of content ... applications implement meaning and behaviour. >1. MARKUP HAS MEANING + BEHAVIOR Or "Content has labels that imply meaning and behaviour to a particular audience" because another audience might have a very different interpretation of meaning and behaviour to the same labels of the same instance. The markup is used for the successful interchange of content ... the content has the implied meaning and the behaviour. >When an XML vocabulary is created each element and attribute is >specified with: > > - a meaning > - the behavior of applications that process the element ... by a particular community of users. > XSLT: the XSLT specification describes the > meaning of <for-each> as well as its behavior: > > - <for-each> identifies a collection of nodes. > That is meaning. > > - A compliant tool must iterate over each node > identified by the select attribute and execute > the nodes within <for-each>. That is behavior. Consider that <xsl:template> has one "meaning and behaviour" for an XSLT processor, but the same element in the same instance has a very different "meaning and behaviour" for my XSLStyle XSLT documentation methodology: http://www.CraneSoftwrights.com/resources/#xslstyle Same labels ... same content ... different interpretation. My stylesheets interpret the construct as having a particular indentation and highlighting because my application is a documentation application, not a transformation vocabulary. In Costello-speak (which I don't agree with) XSLStyle sees XSLT as meaning only, no action. Does that make it "wrong"? >Test suites are created for this kind of XML vocabulary. Test suites >are used for ensuring that applications _behave_ in accordance with >the specification. The test suites are for the applications, not for the vocabulary. One is testing the veracity of the application acting on the labeled content as desired or specified. A schema tests the use of a vocabulary against a particular set of markup constraints ... but the same instance could be validated with different schemas in its life cycle because at different times there may be different markup constraints. >2. MARKUP HAS ONLY MEANING > >When an XML vocabulary is created each element and attribute is >specified with just meaning. No, just labels. Meaning is expressed in the documentation. Unless that is what you mean by "specified with". Different specifications can dictate different behaviours with the same labels of the same instances. The XML vocabulary is no different because the XML vocabulary only specifies the interchange of the content. How the content is used is the scope of a different specification. >1. Why are some XML vocabularies created with meaning + behavior >whereas others are created with just meaning? How about saying "interpretation" instead of "meaning"? Different specifications dictate differently how to interpret the content under the same labels. Thus, to use Costello-speak (which I don't agree with), the same vocabulary will have different "meaning" to different users. Therefore the vocabulary doesn't have "a" meaning, it may have many. >2. I noticed in my examples that the XML vocabularies which specify >meaning + behavior are machine-oriented whereas the XML vocabularies >which just specify meaning are eyeballs-oriented. Should I >inductively conclude that: > > - All XML vocabularies that are machine-oriented should specify > meaning + behavior > - All XML vocabularies that are eyeballs-oriented should specify > only meaning Why do you say "all" and "only"? Is the following "meaning only" or "meaning and behaviour"? <task> <step>Turn off breaker</step> <step>Remove faceplate</step> <step>Disconnect device</step> <step>Remove device</step> <step>Install replacement</step> <step>Install faceplate</step> <step>Turn on breaker</step> </task> The interpretation of "task" is that it collects a set of steps whose relative order represents a relationship between sibling steps beyond just being siblings, that the siblings are ordered. The interpretation of "step" is that it is one of a set of siblings that is ordered after the ones labeled before it and before the ones labeled after it. Do the steps in the wrong order (which isn't the purview of the XML labels) and you can get hurt. In the framework of your question today, does <step> have a behaviour-related meaning? It is describing an action. >3. Is the goal of XML to maximize interoperability? Yes, but only at the level of interpreting the granularity of and labels on content and, in my opinion, no further. The goal of XML is to label content unambiguously to different processors that implement the XML processor the same way. The goal of XML is to deliver the same information to different applications. What people do with the content using their applications is their business and outside the scope of XML. A community of users of a particular vocabulary may wish to agree to handle the labeled content in the same fashion, and they may use a specification with which to come to agreement. A schema shared between users ensures the markup constraints on content are applied the same by all ... "information interchange" is promoted by using XML ... "interoperability" by applications will be up to the specification agreed on by participants. >4. If the answer to (3) is "yes" then shouldn't every XML vocabulary >be specified with both meaning and behavior? How about turning that around: applications are specified with behaviour and the interpretation of labeled content in XML documents that is marked up according to an agreed-upon XML vocabulary and its associated schema. Focus on the content, not on the markup ... the markup is only used to deliver the content and label it. >5. Firefox and IE behave nearly identically. Is that almost >miraculous in light of the fact that the XHTML specification says >nothing about how the markup should behave? I shouldn't think so. The XHTML specification dictates the interpretation of the labels of XHTML and the two development teams implemented the same interpretation for the task of presenting the marked-up content in a web browser. But Firefox and IE and all the other screen browser applications are not the only applications that interpret XHTML. An XHTML document can also be seen as a resource discovery document by an application that has nothing to do with presentation and so isn't at all related to Firefox and IE. That "meaning" for XHTML labels on content is documented in the XHTML specification as "relating online information via hypertext links" with which one using RDDL labels enhances it by describing what kind of content is anticipated to be found at the other end of the link. Your point would seem to imply that the sole purpose of XHTML is to paint a browser screen. >6. I also noticed in my examples that the XML vocabularies which >specify meaning + behavior involve binary operations: > > XML Schema validates XML (The operator is "validate" and the > operands are the XML Schema and the XML) ... when interpreted by a schema validating processor. > XSLT transforms XML (The operator is "transform" and the > operands are the XSLT and the XML) ... when interpreted by a transformation engine. XSLT produces nicely-presented documentation when interpreted by XSLStyle, works successfully, and has nothing to do with a transformation in that context. UBL invoices create cheques to cash at a bank when interpreted by a company that owes someone money. UBL invoices create a pretty piece of paper when interpreted by XSLT/XSL-FO stylesheets. I think you have to dissociate application behaviours from XML vocabularies. Different applications will behave differently with the same XML vocabulary. The vocabulary only enables successful content interchange, not content interpretation. > Whereas the XML vocabularies which just specify meaning involve > unary operations: > > Display XHTML (The operator is "display" and the operand is XHTML) Or the operator is "relate" and the operands are one XHTML document with the source link and a second XHTML document with the anchor. That is two operand "documents" with one operator "relate". Not unary. > Display RSS (The operator is "display" and the operand is RSS) > > Should I inductively conclude that: > > - All XML vocabularies that are involved in binary operations > should specify meaning + behavior > - All XML vocabularies that are involved in unary operations > should specify only meaning I wouldn't. >7. For perfect (or nearly perfect) interoperability, must an XML >vocabulary specify both meaning and behavior? An XML vocabulary specifies only the interchange of information between applications and does so by using labels and granularity. A community of users must agree to deal with the labeled content in agreed-upon ways. A different community of users must agree to deal with the same labeled content in their agreed-upon ways. I hope this helps. . . . . . . . . . Ken -- XSLT/XQuery training: after http://XMLPrague.cz 2011-03-28/04-01 Vote for your XML training: http://www.CraneSoftwrights.com/x/i/ Crane Softwrights Ltd. http://www.CraneSoftwrights.com/x/ G. Ken Holman mailto:gkholman@CraneSoftwrights.com Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/x/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[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