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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri-comment message

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


Subject: RE: [xri-comment] Comments on the requirements document


Lars Marius-

Thanks for your feedback. As noted in the original post, it is just a
strawman, so significant holes are to be expected.

Your feedback, however, is invaluable as a outside set of eyes. Much
appreciated..

	-Gabe

> -----Original Message-----
> From: Lars Marius Garshol [mailto:larsga@garshol.priv.no]
> Sent: Monday, January 13, 2003 12:37 PM
> To: xri-comment@lists.oasis-open.org
> Subject: [xri-comment] Comments on the requirements document
> 
> 
> 
> Hi everyone,
> 
> I'm one of the people working on topic maps standardization, both the
> published subjects work here in OASIS as well as the core standards
> work in ISO.
> 
> I've read through the requirements document and also been introduced
> to this work on IRC by Gabe Wachob. Gabe was quite helpful, but I have
> to say the document itself does not give a very clear picture of what
> the TC intends to do.
> 
> The first thing that would be useful would be a clearer list in
> section 1 of the deliverables. That is, names (or even numbers) for
> the deliverables, and a bit more detail on what is actually going to
> be in each. The first is quite clear, but what's in the second? A
> protocol? A data model? An interchange format? Anything else?
> 
> In section 2 the definition of "directory" appears to be missing. It
> may also be useful to add that "resource" as defined there appears to
> be identical to the "resource" of RFC 2396 and the term "subject" in
> topic maps. Also, a "version", is that truly a state of the resource
> or just a state of the data about it?
> 
> In section 3 it would help a lot of the requirements were reorganized
> so that it was clear which requirements applied to which deliverable.
> Also, in 3.1 points 2-4 are very vague. I can't really make out what
> they are saying. Number 9 seems to imply that there will be a data
> model, but nothing has been said about any such model earlier. To see
> a list of the technologies the TC intends to create would make
> evaluating these requirements much easier.
> 
> In section 3.2, point number 2 seems to say that it should be possible
> to encapsulate URIs from other URI schemes within XRI URIs, almost
> like with the tdb: URIs proposed by Larry Masinter. Is that really
> what it is saying? If so, why?
> 
> Point 4 (of 3.2) talks about a "root", but I have no idea what that
> means.
> 
> Points 6-7 (of 3.2) seem internally contradictory. Is there going to
> be a single XRI URI scheme, or multiple ones?
> 
> Point 8 (of 3.2) talks about "parent resources", but what they are is
> not clear. Is the XRI data model hierarchical? How does that fit with
> attributes? And are attribute types themselves resources, BTW?
> 
> At the end of section 3.2 there is also talk of an XRID namespace.
> What is that? Does it have any relation to the URI scheme(s)?
> 
> In section 3.3, point 3, should it say "use" rather than "support"?
> One missing requirement in this section seems to be an interchange
> format for the data model one presumes is going to be part of this.
> 
> In section 3.5, point 2, there is talk of "completely decentralized
> resolution". What is that?
> 
> In section 3.6, point 2, it is said that the specifications must be
> language-independent. What does "language" mean in this context?
> Surely not natural language?
> 
> 
> Lots of questions, and rather less advice. I hope it is useful even
> so. 
> 
> -- 
> Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
> GSM: +47 98 21 55 50                  <URL: 
> http://www.garshol.priv.no >
> 


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


Powered by eList eXpress LLC