Re: [xml-dev] What is declarative XML? (And what's not)

[Frank Manola <fmanola@acm.org>]

Roger--

I guess I'd like to hear more about some of the definitions you're  
using, right now in particular definitions for "symbiotic  
relationships" and "processing semantics".  In the case of "symbiotic  
relationships", one definition requires that the relationship be  
beneficial to *both* parties (as opposed to, say, "parasitic").  Is  
that what you mean?  If so, could you explain how the symbiosis takes  
place using *only* local semantics?  In the case of "processing  
semantics", what kind of processing do you have in mind?  In  
particular, semantics that fully specify any processing to take place  
seem to me only one type of "processing semantics".  How about  
semantics that *constrain* the types of processing to those that make  
"semantic sense", while not fully specifying it?

Consider your purchasing example.  It seems to me that such uses have  
the most value when the various parties that share the data also agree  
(or mostly agree) on the semantics, e.g., on what terms like  
"purchase", "cost", "currency", "merchandise", etc. mean (in fact, I  
have trouble imagining any symbiosis, using the specific definition I  
mentioned above, if there isn't such agreement).  But then this shared  
semantics isn't "local", at least not in the sense I think you  
described;  it's common to both (in this case) producer and  
consumers.  Moreover, the maximum symbiosis is obtained when any  
processing that is done is consistent with (constrained by) those  
shared semantics.  E.g., while there's no rule that says that a  
receiver of this purchase data can't do whatever they want with it,  
I'd say that the likelihood of symbiosis is reduced if the receiver  
doesn't process the value of the "cost" element consistently with what  
the producer meant by "cost" (and still further as constrained by the  
semantics and value of the "currency" attribute).  Note that this  
requirement doesn't fully *specify* processing, but it does  
*constrain* it;  and that's generally what semantics do (and, of  
course, if you ignore the intended semantics you can do whatever you  
want).

In short, I think the continuum you mentioned needs to be further  
described and filled in.

--Frank


On May 31, 2009, at 7:42 PM, Costello, Roger L. wrote:

>
> Frank Manola wrote:
>
>> Could you say a bit about what your goals are
>> for making this distinction?
>
> I shall try.
>
> My goal is to enable symbiotic relationships - applications that  
> share externalized data and act on it using local semantics.
>
>
> Whew! Lots of explanation is needed to explain that sentence. Let me  
> try...
>
> (Walter Perry if you're still out there please jump in. Your ideas  
> from 10 years ago have germinated and are sprouting quickly. And Len  
> Bullard if you're still out there lots of your ideas are in here too.)
>
>
> The distinction I am making is between:
>
>    XML documents that are devoid of processing semantics.
>    More accurately, the markup is devoid of processing
>    semantics. These documents announce to their recipients,
>    "Here I am, use me in whatever way makes sense to you.
>    YOU are responsible. YOU are in charge."
>
> versus
>
>    XML documents that have inherent processing semantics.
>    These documents announce  to their recipients, "I must
>    be processed according to my terms. I am responsible.
>    I am in charge."
>
> A key difference is between local control versus control by an  
> external entity.
>
> Suppose two parties are symbiotically sharing an XML document -  
> mining it, morphing it, and mashing it up. Imagine each party has  
> different needs. The document must be neutral in its processing  
> requirements. Each party must be capable of applying local  
> processing semantics.
>
>
> Apparently the term "declarative XML" already has a specific  
> meaning. From Kurt and Dimitre's messages I realize that I have used  
> the wrong term. I am not talking about functional programming. In  
> fact, just the opposite.
>
> I am talking about something else. I am talking about these kinds of  
> documents:
>
> XML-devoid-of-processing-semantics-and-local-processing-semantics- 
> must-be-applied
>
> Whew!
>
> For brevity perhaps we can call them:
>
>    Local Semantics Documents
>
>
> Frank also keenly observed:
>
>> Suppose I have a reasonably complete music markup language.
>> From one point of view this is pretty declarative, since
>> it just describes the notes, sequences, rhythms, etc.
>> (e.g. consider an ordinary piece of sheet music).  On the
>> other hand, it has a pretty obvious "processing semantics":
>> you play it on something, and while part of those
>> "processing semantics" may be local (e.g., what you decide to
>> play it on) another isn't "local" (you follow the note sequence,
>> etc., specified in the music).  So in this case your distinction
>> between "declarative" and not doesn't seem all that stark.
>
> Excellent!
>
> There is a continuum. At one end are XML documents that have clearly  
> defined, inherent processing semantics, such as XSLT documents. On  
> the other end are documents that have no inherent processing  
> semantics. The purchases example I presented lies on that end. The  
> music example Frank presented lies real close to that end.
>
>
> I assert that documents that have no inherent processing semantics  
> have substantial benefits in terms of reusing them and mining them  
> and mashing them up.
>
>
> My goal? Enable symbiotic relationships - externalized data that is  
> shared by two or more parties and acted upon using local semantics.
>
> Comments?
>
> /Roger
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>