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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri-editors message

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


Subject: RE: [xri-editors] Proposals for XRI Descriptor priority attribute


Okay, Gabe, so what you are saying is that it isn't worth it to explicitly
say that in the absence of a priority attribute, the consuming application
should rely on document order, but instead just say that in the absence of a
priority element, priority is up to the consuming application (and
proceeding in document order is simply one strategy you can take).

I'm fine with that. Is this issue closed then (save for review of the actual
text you propose?)

=Drummond 

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Wednesday, June 22, 2005 9:49 AM
To: Lindelsee, Mike ; Drummond Reed; Peter Davis; Wodjenski, Sharon;
xri-editors@lists.oasis-open.org
Cc: Chasen, Les; Zhang, Ning; Tran, Trung
Subject: RE: [xri-editors] Proposals for XRI Descriptor priority attribute

Mike-
	With regards to document order - it needs to be preserved for
the purpose of applying and verifying digital signatures (ie the Trusted
Resolution mechanism we define in the resolution spec). 
	Preservation of document order is not, strictly speaking,
required for consuming/processing XRIDescriptors documents (you can
reproduce ordering through the chaing of resolved and authorityID
elements) either. That being said, the XRIDescriptors document *is*
required to have the XRIDescriptor elements in order, so an XML
processor that preserves order (honestly, I'm not sure of one that
doesn't) would make an implementer's life a lot easier. 
	Net-net is that I think we should NOT have document order be a
default. Actually its not going to matter if that's the 3rd and optional
default because if we don't say to use document order at all, each
implementation is free to do what it wants anyway... Which may be
document order or not. 

	-Gabe

> -----Original Message-----
> From: Lindelsee, Mike 
> Sent: Wednesday, June 22, 2005 9:07 AM
> To: Drummond Reed; 'Peter Davis'; 'Wodjenski, Sharon'; 
> Wachob, Gabe; xri-editors@lists.oasis-open.org
> Cc: 'Chasen, Les'; 'Zhang, Ning'; 'Tran, Trung'
> Subject: RE: [xri-editors] Proposals for XRI Descriptor 
> priority attribute
> 
> Comments inline... 
> 
> >-----Original Message-----
> >From: Drummond Reed [mailto:drummond.reed@cordance.net] 
> >Sent: Tuesday, June 21, 2005 5:12 PM
> >To: Lindelsee, Mike ; 'Peter Davis'; 'Wodjenski, Sharon'; 
> >Wachob, Gabe; xri-editors@lists.oasis-open.org
> >Cc: 'Chasen, Les'; 'Zhang, Ning'; 'Tran, Trung'
> >Subject: RE: [xri-editors] Proposals for XRI Descriptor 
> >priority attribute
> >
> >We still need the priority attribute to handle two use cases:
> >
> >1) Resolver or resolving application does not handle/preserve 
> >XML document
> >order;
> >
> 
> Understood, but doesn't XML document order need to be 
> preserved in any case?  Actually, this may only be for the 
> case of trusted resolution.  Dave, Gabe -- any input on this?
> 
> >2) Authority producing the XRID wants to explicitly express that two
> >Authority/Service/Internal Synonym/External Synonym/URI 
> >elements have the
> >same priority.
> >
> 
> This case makes sense to me and definitely requires more 
> information than was originally in the XRID.
> 
> 
> >So the proposal is only to add one more layer to Peter's 
> >proposal, i.e.,
> >process element priority in this order:
> >
> >1) Priority attribute
> >2) If not present, XML document order
> >3) If not possible, random order
> >
> >That said, if inserting document order as a middle step 
> seems odd, then
> >scrap it and let's just go with Peter's proposed language.
> >
> 
> I think your proposal is sensible and am all for handling 
> priority with the three steps you outline above.
> 
> Mike
> 
> 




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