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

Re: 'is-a' Relationships in XML?

  • From: Jonas Mellin <jonas.mellin@his.se>
  • To: stephengreenubl@gmail.com
  • Date: Tue, 04 May 2010 09:02:49 +0200

Re:  'is-a' Relationships in XML?
stephengreenubl@gmail.com wrote:
> Would I compare XML's limited isA capabilities and strong hasA capabilities to programming languages? Yes, to structs in C. They need added naming conventions to express isA, just as XML on its own without XSD can easily express containment but needs naming conventions like OASIS UBL's NDR plus CEFACT's CCTS to express 'isA'. 
Hmm, strong "has-a"? It depends on what you mean by "has-a". In
modelling, there is typically a distinction between "has-a" (in the
intepretation "consists-of") and "related-to" (which can be expressed as
"has-a-relation-to"). In both C and XML there is no way to tell whether
you mean "has-a" in the interpretation "consists-of" or the weaker
"related-to" from the construct itself. By naming, you may express
relations, which may be interpreted according to your intentions.

One part of data-modelling is to fit the model with respect to the
queries/processing that is applied to the data. This may result in data
models where the parent-child structure is not used for expressing
"has-a". One way of generating such models are to define data in more
one-to-one relationship with the relations in the world and then
generate these models. An common-place example of this is
index-generation in SQL databases or the virtual method tables generated
by compilers in, for example, C++. You also have column-store database
(rather than row-store databases), non-relational databases etc.

A Michael Kay noted, there are good models and bad models. In my view, a
good model fulfills the expectations of the stakeholders, which we try
to capture in the requirements. So, by fulfilling the requirements we
strive to meet these expectations. In a good model, the parent-child is
not necessarily used for "has-a" in the intepretation of "consists-of",
but can be used for weaker relationsships such as "related-to",
"associated-to". Further, constraints such as cardinality etc. may or
may not be captured in the data model.
> In contrast take more modern OO languages features like C#'s struct or take W3C OWL expressions, where isA comes built-in. 
In which there is a model of interpretation including the semantics of
is-a. The intention of XML is, AFAIK, to provide a syntax for data
modelling. Since "is-a" can be used for various purposes (e.g., reuse or
specialization), it would be limiting to adopt either and it is
confusing to adopt both (e.g., see various mistakes in OOA&D).
> Even XSD can't well compete with these. It would be handy, essential even, to be able to say of an element in one schema that it isA element or type in another. Not just rely on what the XSD authors of the first schema had the temerity and foresight to facilitate. Maybe XSD 1.x? But there seems to be agreement here that XSD is not the tool for this when we are talking semantics rather than structure and there the comparison with C# structs also ends but that leaves OWL, etc.
>   
In what sense do you want to use "is-a", reuse, specialization or both?
Concerning multiple inheritance, how do you propose to handle conflicts?

/Jonas Mellin
> Thanks
>
> Stephen D Green
>
>
> -----Original Message-----
> From: Jonas Mellin
> Sent:  04/05/2010 1:13:48 am
> Subject:  Re:  'is-a' Relationships in XML?
>
> stephengreenubl@gmail.com skrev 2010-05-04 01:46:
>   
>> But back to my initial question and the responses, it seems safe to conclude that while semantics should be explicitly defined somewhere other than the markup alone or XSD, etc, any implicit semantics are easier to see in the markup when they concern 'hasA' relationships of belonging but not so clear when they involve 'isA' relationships of inheritance or equivalence because these can only really be represented using a schema like XSD. This seems peculiar to XML. So this seems another reason to separately define the semantics formally of any markup and not to leave it just to what is implicit in the structure and node names.
>>    
>>     
> I can guess what you compare XML to, but I would like you to be more 
> specific to understand "This seems peculiar to XML". So, what do you 
> compare XML to, C++?
>
> Concerning semantics, a great debate in object-oriented programming was: 
> is a square a rectangle or is a rectangle a square? (differentiating 
> between pragmatics and semantics). The answer is, it depends. 
> Mathematically, a square is a special case of a rectangle. However, 
> pragmatically, if a rectangle is a square, then we only need one member 
> variable to maintain square objects and rectangle objects use this 
> member variable and adds another. Thereby, we can save space. So, even 
> if you have a language with "is-a" relationships, the meaning may not be 
> clear. Of course, we can add meaning but making one of the uses of 
> "is-a" illegal within some context such as a project or an organization 
> or a standard. Further, there are languages disallowing the pragmatic 
> use of is-a relationsships.
>
> Anyway, even though we have languages to express certain constructs, it 
> may be desirable to separately define the semantics formally.
>
> /Jonas Mellin
>   
>> Stephen D Green
>>
>>
>>
>> -----Original Message-----
>> From: stephengreenubl@gmail.com
>> Sent:  04/05/2010 12:32:03 am
>> To: Michael Kay; stephengreenubl@gmail.com
>> Cc: 'xml-dev'
>> Subject:  RE:  'is-a' Relationships in XML?
>>
>> But clearly the markup can need more explanation via semantic definitions or specifications than would be needed by straight prose statements. E.g. I can lie by stating that I own Buckingham Palace. That implies Stephen D Green owns Buckingham Palace and this is not true. If I write markup<place name='Buckingham Palace'><owner>Stephen D Green</owner>then it depends what 'owner' means as to the truth and meaning of the markup. It could be the same lie as above or it could be the start of a document about a place where I was owner of the document, not owner of the place. So yes I accept to some extent what folk here are saying but with some reservation, as I think would anyone since we always leave some understanding of the semantics to the markup itself and don't express all of it in the spec and related defining artefacts. Plus we tend to let the schema express some semantics, as I was advised in early responses here, without perhaps restating all such semantics in a spec. We understand though the dangers and risks and address the clearest risks by making some semantics like calculation models explicit in a spec, perhaps even using formal logical english or a calculus. Or we create other artefacts specialised for expressing semantics like topic maps or ontologies and take it, in doing so, that the markup and maybe XSD do not adequately cover semantics but rather are optimised to express structure and constraints on structure. That makes sense.
>> Thanks
>> Steve
>> Stephen D Green
>>
>>
>> -----Original Message-----
>> From: stephengreenubl@gmail.com; stephengreenubl@gmail.com
>> Sent:  03/05/2010 11:49:25 pm
>> To: Michael Kay
>> Cc: 'xml-dev'
>> Subject:  RE:  'is-a' Relationships in XML?
>>
>>
>>
>>
>> -----Original Message----
>> From: Michael Kay
>> Sent:  03/05/2010 11:35:35 pm
>> To: stephengreenubl@gmail.com
>> Cc: 'xml-dev'
>> Subject:  RE:  'is-a' Relationships in XML?
>>
>>    
>>     
>>> So making an 'employee' element  a child of an 'employer'
>>> element clearly implies some semantics that the employer
>>> 'has' the employees.
>>>      
>>>       
>> And if 'employer' is a child of 'employee' then I suppose that the employee
>> "has" the employer. But I don't think there's any semantics here: you're
>> just using "has" as a synonym for "is the parent node of".
>>
>>
>> -sdg:
>> Not really. I think I'd be understanding that the markup was using the parent/child to represent the reality of the 'has' relationship. I accept that it's implicit to some extent but even the names of the elememts could be said to imply something about the reality being represented. Just as words represent reality, to some extent implicitly.
>>
>>
>>
>> If XML is well designed, then you can make guesses about the meaning of the
>> data from the choice of element names and their hierarchic relationships.
>> But XML is often badly designed, and your guesses in such cases will be
>> wrong.
>>
>> Regards,
>>
>> Michael Kay
>> http://www.saxonica.com/
>> http://twitter.com/michaelhkay
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________________________________
>>
>> 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
>>
>>    
>>     
>
>
>
> _______________________________________________________________________
>
> 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
>
>
>
> _______________________________________________________________________
>
> 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
>
>   


-- 
Carpe Diem!
===
Jonas Mellin, Assistant Professor in Computer Science
School of Humanities and Informatics, Building E-2
University of Skövde, P.O. Box 408, SE-541 28 Skövde, Sweden
Phone: +46 500 448321, Fax: +46 500 448399
PGP Public Key: http://www.his.se/PageFiles/19377/Jonas_Mellin.asc
Email: jonas.mellin@his.se, URL: http://www.his.se/melj, 

----BEGIN GEEK CODE BLOCK----
GCS d s a+ C++ UL++ US++ P++ L++ E++ W++ N+ o K- w++ O- M V-- 
PS- PE+ Y+ PGP t+ 5 X R* tv- b++ DI+ D+ G+ y++++ e++++ h--- r+++
----END GEEK CODE BLOCK----


OpenPGP digital signature



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

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.