|
Hans,
The analogy to a URI/URL is brilliant and it is new to me. Never before have I seen OID explained in those terms. It replaces any analogy I ever made to ETag, that might mis-emphasize caching and confuse the concept more than this URI/URL analogy. I cannot add much to this, except that the "uniqueness" of OID is scoped by the implementation just like a database index. In perfectly "normalized data", you will find a relation to best OID values and your DBMS index values. Brian Date: Mon, 31 Mar 2014 05:09:36 +0100 From: hrennau@yahoo.de To: xml-dev@lists.xml.org CC: xmlboss@live.com Subject: [xml-dev] OID vs. a new node property The OID pattern to which Brian Aberle introduced us seems to me very
interesting, as it throws light on a peculiarity - perhaps weakness - of
the XML information model: the XML model is unrelated to the concept of
a resource as it underlies the web, as an abstract entity to be
distinguished from the representations which we transfer and use to read
and update the resource. This unrelatedness is reflected by the infoset
and XDM models: an XML document (and its elements) does not have any
property capturing the resource which it represents. Citing from Roy Fielding's dissertation: "More precisely, a resource R is a temporally varying membership function MR(t), which for time t maps to a set of entities, or values, which are equivalent." I think the OID may be regarded as a special kind of resource locator, URL, that is. The OID is found in some incoming entity, and identifies a local entity which is related to the incoming entity in a very special way: they are both - incoming and local - two representations of the same resource, representing two of its states. Two possible views of the OID. On the one hand, it locates a particular resource representation, as a href does. But this view does not express the fact that both representations, the OID asserting one, and the OID matching one, are two representations of the *same* resource. Therefore I suggest to regard the OID as not only identifying a resource representation, but - implicitly - identifying the resource itself. So the OID is an URI identifying the resource which is represented by the fragment asserting it. Or perhaps the resource is represented twofold, by the entity asserting the OID, as well as by the entity matching the OID. Identification of the resource itself enables the *alignment* of resource representations - this one and that one are discovered to represent the same resource - and this knowledge can be put to good uses, for example one can be treated as an update of the other. Where do we stand? The document node has a property [document-uri], which clearly identifies a resource representation, not the resource itself. For example, copy the file, and the result has a new [document-uri]. The XML information model simply lacks a property which can capture the resource being represented. IMAGINE that the document node and any element node had a further node property: [resource-uri], which identifies the resource represented by the document or element in question. Being a property of the element or document, it would not be an information item in its own right, for example it would not be an attribute. Once one has accepted this idea, tentatively, syntax might follow and enable some serialization of the property. This could be a pseudo-attribute - e.g. @xml:resource - which only looks like an attribute, but is in fact only a syntactical indicator of a node property - exactly as is the case with namespace attributes. It could also be a really new syntax feature (e.g. <foo#http://example.com/> - and it could be Brian's OID attribute with its peculiar constraints. The difference may be importatant in practical terms - but from a conceptual point of view it is not nil, a mere reflection of the fact that documents and elements have an inherent property capturing the resource which is represented. Kind regards, Hans-Juergen Rennau |