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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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


Subject: RE: [xri] XRI Resolution 2.0 Draft 09 comments


Re patterns, I like the idea but accepting regular expressions from the average citizen scares me.  What happens if a regular expression is poorly formatted?  Are there scenarios that could cause very bad consequences like memory/CPU problems to applications crashing?  Also, if we are going to accept patterns do we in the spec need to specify the rules behind them?  Do we need to refer to a regular expression spec if there is such a thing?  These fears may not be rational but those are my thoughts at this moment.  I tend to think this type of advanced feature belongs in a specialized service application. 

 

If it is decided to keep them, the GRS will not be able to support the provisioning of this data in the initial release this February.

 

 

 

 

 

I-Name:  =les.chasen 

 


From: Tan, William [mailto:William.Tan@neustar.biz]
Sent: Friday, November 11, 2005 11:07 AM
To: xri@lists.oasis-open.org
Subject: [xri] XRI Resolution 2.0 Draft 09 comments

 

Hi all,

 

Here are my comments/suggestions/questions regarding the newly submitted draft. Please let me know if I’ve misread something.

 

1. xrd:XRD/xrd:Service/xrd:Pattern – what flavor of regular expression should the value be (perl-compatible, posix, etc.)? Is the full power of regexp really required, why not just simple string comparison or prefix matching?

 

2. Line 393 – how about wording it like “A synonym is an XRI that, in its normalized form, differs from another normalized XRI, but which identifies the same target resource …”? Just to make it clear that an un-normalized XRI and its normalized version are not synonyms.

 

3. If table 4 and 5 on pages 13 and 14 can be combined so both examples show up side-by-side it would help readability a great deal. Perhaps removing the “www.” from the xref root may save some space.

 

4. Section 2.8 Versioning - if the version attribute is optional, implementations may take the shortcut to ignore its presence thereby defeating the purpose of versioning. A newer version may not change the schema but we may want the possibility of modifying the semantics of the elements or attributes. We may not have that choice should implementations do not respect version information.

 

5. Section 6.3 – why MUST the proxy resolution server perform lookahead resolution? Why can’t it perform subsegment-by-subsegment resolution?

 

6. Section 3.2.7 – What’s the difference between <Synonym xref=”true”> and <XSynonym>?

 

Thanks.

 

wil.



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