[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: re: Dotted-name Tags (was RE: Long Tags Codes etc. again)
Message text written by John McClure >For <Purchaser.FirstName>, the Interpreter learns from the DCD that 'FirstName' is a subclass of "Memo" and "Entry", and is valid for resources of type 'Person'. It also learns that 'Purchaser' is a subclass of 'ActorRole' and 'Role'. Put these facts together, and the appropriate DOM tree can now be generated with little problem. There are enough other pieces to this that it is appropriate to call this kind of markup a DCN-specific <!NOTATION>, a subtype of the XML notation embedded in parsers today. In part because the notation generates a DOM tree that is DCN-specific, using elements from a DTD that is expected to change very little over time. And in part because there is no difference (the same DOM fragment is generated) between <<<<<<<<<<<<<<<<<<<<<<< John, This is interesting - and I personally would like to explore this in the context of TREX - where I see some interesting overlaps and potential to build on an emerging simplified schema system that would directly support alot of this. You further stated >>> I must admit to remaining puzzled over why UIDs seem so attractive in the face of URIs and XML Namespaces. Mark Crawford's beliefs seem rooted in an XML Schema and DTD world, one that I hope fervently is left behind by the RDF Schema world coming upon us. <<< Here's the rub - your wonderful example above top is a classic example : For <Purchaser.FirstName>, the Interpreter learns from the DCD that 'FirstName' is a subclass of "Memo" and "Entry", Now - the problem is - what if my interpreter does not 'learn' quite the way your does? The human is certainly not going to be able to unravel all the hidden nuances of all this layer on layer on layer abstraction with RDF, URI's and Namespaces. Whereas the simple and direct UID provides a goof-proof associative mechanism that can be manually cross-checked and verified and implemented. Too many of us have been in the trenches of data transactions and prefer something direct and simple. Once we have that all working then we can build from there to reach for the potential wonder of what you are engineering. Just practical implementation in a business context. Thanks, DW.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC