[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: [xml-dev] 'is-a' Relationships in XML?
- From: "stephengreenubl@gmail.com" <stephengreenubl@gmail.com>
- To: "Michael Kay" <mike@saxonica.com> , "stephengreenubl@gmail.com" <stephengreenubl@gmail.com>
- Date: Mon, 03 May 2010 23:46:52 +0000
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.
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: [xml-dev] '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: [xml-dev] '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: [xml-dev] '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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]