OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

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


Subject: RE: [xdi] 3 key XDI metaschema issues


Hi everybody: 

I have just posted my version of the XML schema to the site. 
It is a very simplistic one, and I have other ideas around it, such as
using "ref" so that it would be easier to use XPath, but for the time
being, I have opted to keep it at that. 

As far as I remember, there has been fair amount of discussion over
point 1 and 2 during the last call. I am adding a few comment to the
point 3 here. 

(For those of you who were not at the f2f nor the last call: I have
thrown into many more tags so that we can discuss about the "concrete"
elements.) 

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> XDI TC Members and Observers:
> 
> 
> 3) LINK AS AN ELEMENT OF RESOURCE
> 
> In the proposed XSD, there are separate elements for Resource and
Link,
> however except for the tag, their element definitions are identical.
In
> Nat's object model, Link becomes a subelement of Resource, so you know
a
> Resource is a link if the Link element is present.
> 

Well, this is not true. In my model, Link Contract is an
extension/subclass of Resource, because I am introducing more structure
to the Link Contract. If it were to remain just as in Drummond's case,
then it would not even be a subclass: it merely is going to be a type of
Resource.  

> PROS
> * More efficient object model, since all objects are Resources.
* More rigorous structure for Link Contract: Yes, it could just be
represented as resource, but I thought that this type of object is
important enough that there should be a way to validate the format at
the XML Schema level. Also, from the marketing point of view, having
this kind of un-normalization would help people understand what it
really is. 

> 
> CONS
> * A Resource tree must be traversed in order to determine if it is a
Link.

No: Schema and XML document is different. You do not traverse the
schema, and you can always have two trees for Resources and "Links"
whichever the schema you choose. 

> * Introduces the problem of addressing Resources (data for which an
> authority is authoritative) vs. Links (data which is cached from
another
> authority). The address of the Link already uniquely identifies the
XDI node
> (since a node can only have one Link to another node), however a
Resource
> can also have its own XRI. So if they are combined, are you addressing
the
> Resource or the Link? The proposed metaschema addressing mechanism
makes
> this distinction syntactically precise.
> 
This is not true either. They are different classes, and there is no
difference between Drummond's model and mine with regard to it. Either
way, it is clear for the user if it is a Resource or "Link". 

Only the difference is whether one class is derived from another or not,
and whether one to have richer structure or not. 

Nat



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