[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: The Myth of Explicit Relationships [Was: 3 XML DesignPrinc


xml aware application
Roger--

I agree with (what I think is) the general idea you're getting at, but 
the way you put it is sometimes imprecise.  In particular, you sometimes 
fail to identify *what* semantics or relationships you are talking 
about, and *to whom* the XML is supposed to convey those semantics.  For 
example, you say below that "it is not possible for XML markup to state 
explicit relationships".  Clearly this is wrong as stated:  XML markup 
can state explicit relationships that are relevant to XML markup (like 
element containment, and which attributes go with which elements) to an 
XML processor.  Similarly, XML markup can state semantics that are 
relevant to XML markup to an XML processor.  Later on, you start to be 
more specific about this sort of thing.

You might also want to explicitly consider the "eXtensible" part of XML: 
  it's role in defining and carrying the syntax of languages meant to be 
layered on top of it.  For example, RDF/XML is layered on XML.  Given 
some RDF/XML, an XML processor wouldn't recognize what the RDF 
relationships were, but an RDF/XML processor would.  However, a generic 
RDF/XML processor wouldn't necessarily recognize what those 
relationships "meant", unless the relationships were part of the RDF 
vocabulary itself (like rdf:type relationships).  Relationships specific 
to other vocabularies (like the Dublin Core dc:author relationship) 
would require a processor designed to operate on that vocabulary.  And 
so on.

--Frank

Roger L. Costello wrote:
> Hi Folks,
> 
> This past week we discussed implicit versus explicit relationships.
> This morning I carefully reread every message.  
> 
> Several people commented that "XML Doesn't Care" and "XML is just syntax".
> I'd like to apply those comments to the notion of explicit relationships.
> 
> In this message I would like to reverse my stand and argue that
> it is not possible for XML markup to state explicit relationships.
> I will argue that explicit relationships in markup is a myth.
> 
> Consider this markup:
> 
> <Lot id="1">
>     <Picker id="John">
>         ...
>     </Picker>
> </Lot>
> 
> What's the relationship between the Lot and the Picker?
> 
> The tag names have meaning to us as humans.  Thus, it is tempting for us to
> read the markup and infer a relationship that in fact does not exist. 
> 
> To an XML parser the markup looks like this:
> 
> <W#*jQ10x>
>     <p99@% I8s="John">
>         ...
>     </p99@%>
> </W#*jQ10x>
> 
> That is, to an XML parser the tags are just a collection
> of meaningless characters.
> 
> The advantage of us humans viewing the markup in this later form is that it
> lessens
> our overwhelming temptation to infer meaning.  Oddly, the relationship 
> becomes clearer! We now see that the relationship is simply:
> 
>     p99@% is nested within W#*jQ10x
> 
> Or:
> 
>    Picker is nested within Lot
> 
> No other statements can be made regarding the relationship
> between the Lot and the Picker.
> 
> Thus, it is erroneous to state this relationship: 
> 
>    The Picker is located on the Lot
> 
> This "located on" relationship may not be stated.  It is bringing
> in knowledge that is not present in the markup.  (The knowledge
> is coming from the mind of the reader)
> 
> In fact, even the "nested within" relationship is only known if
> the processing application happens to be an XML-aware application.  A
> non-XML-aware
> application would not even be able to recognize the "nested within"
> relationship.
> 
> I make these two assumptions for this discussion:
> 
> 1. The processing application is an XML-aware application.
> 2. The processing application is completely ignorant of our vocabulary.
> 
> Let us continue with our example.
> 
> Suppose that we decide that the "nested within" relationship is not
> sufficiently
> precise for our desires.  Can we design the markup to make the 
> relationship more precise? 
> 
> How about this:
> 
> <Lot id="1">
>     <locatedOn>
>         <Picker id="John">
>             ...
>         </Picker>
>     </locatedOn>
> </Lot>
> 
> It would appear that the <locatedOn> element is making explicit 
> the relationship between the Lot and the Picker.
> 
> It is best to resist the temptation of our mind to add knowledge to the
> markup.
> So, let us convert the example into something less interpretable by our mind
> (but
> equally interpretable to a machine):
> 
> <W#*jQ10x>
>     <vb*@34>
>         <p99@% I8s="John">
>             ...
>         </p99@%>
>     </vb*@34>
> </W#*jQ10x>
> 
> This makes it clear that the only relationships which can be stated are:
> 
>     p99@% is nested within vb*@34, which is nested within W#*jQ10x  
> 
> or:
> 
>    Picker is nested within locatedOn, which is nested within Lot
> 
> Introducing the locatedOn element has done nothing to make the relationship
> between the Lot and the Picker more explicit.  It has only served to push
> the Picker 
> to a deeper nesting level (and thus more digging is needed to get at it).
> 
> Any relationship information beyond "nested within" must be introduced
> outside the markup, i.e., 
> by human-engineered applications that process the markup.
> 
> Conclusions/Observations/Questions
> 
> 1. No matter how you design your XML it won't make any difference in
> semantics.
>    Specifically, nested elements will always yield the "nested within"
> relationship
>    and nothing else.
> 
> 2. There is no such thing as markup that enables you to specify an "explicit
> relationship"
>    between components.  Any relationship semantics beyond "nested within"
>    is entirely a product of the application processing the markup.  
> 
> 3. XML places the whole burden of semantics squarely upon the shoulders of 
>    processing applications. Consequently, the sender and receiver must
>    necessarily be tightly coupled (i.e., have shared semantics).
> 
> 4. All message exchanges are nothing more than a series of encodings and
> decodings.
> 
>    For example, this message:
> 
>      "The Picker whose name is John, is currently located on Lot number 1"
> 
>    May be encoded like this:
> 
>    <Lot id="1">
>       <Picker id="John">
>           ...
>       </Picker>
>    </Lot>
> 
>    Or it may be encoded like this:
> 
>    <W#*jQ10x>
>       <p99@% I8s="John">
>           ...
>       </p99@%>
>    </W#*jQ10x>
> 
>    Either is a perfectly fine encoding.  Communication occurs when the
> receiver
>    possesses the proper decoder.  Thus, a decoder must be able to decode the
> 
>    above code back into the original message:
> 
>     "The Picker whose name is John, is currently located on Lot number 1"
> 
>    If the receiver does not have the proper decoder then communication
> cannot occur.
> 
> 5. Is it conceivable that a code could be processed by many different
> decoders?
> 
> 6. Are there such things are "self-decoding codes"?  (I guess that a virus
> is
>    an example.)
> 
> 7. Is it reasonable that a generic message format (i.e., XML) should carry
> at least some of
>    the burden of semantics?  Should XML 2.0 possess more semantics than is
> currently found
>    in XML 1.0?
> 
> Comments?  /Roger
> 
> 
> 
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
> 
> 

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.