XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] OID vs. a new node property

Hi,

It occurs to me that a document 'fragment' identifier, at least as it is used in the RDF world, has this global identifier role essentially.

e.g. http://blog.iandavis.com/2007/11/29/its-ok-to-use-uris-with-fragments-in-rdf/

The fact that an XML ID attribute only has guaranteed document uniqueness seems a sad thing given the RDF sense of it.

Also, I keep thinging that AtomPub is essentially what Brian is wanting to achieve but a high-performance variant of it.

Regards
Steve Cameron


On Mon, Mar 31, 2014 at 3:09 PM, Hans-Juergen Rennau <hrennau@yahoo.de> wrote:
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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS