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] Data Interoperability ... Why do some XML vocabularies specify meaning + behavior whereas others specify only meaning?

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.


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 


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.

>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"?

      <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>

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]

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