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

["Drummond Reed" <drummond.reed@cordance.net>]

Okay, then I'll resubmit the proposal that the normative text should say to
process element priority in this order:

1) Priority attribute if present
2) If not present, XML document order if preserved
3) If not preserved, random order

Are there any other objections, or can we close this issue?

=Drummond 

-----Original Message-----
From: Lindelsee, Mike [mailto:mlindels@visa.com] 
Sent: Thursday, June 23, 2005 9:52 AM
To: Sakimura, Nat; Drummond Reed; Wachob, Gabe; 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

As I see it, the issue is that we've already said that we can't rely on
parsers to maintain document order.  If that is the case, then the
document order a resolving client sees has to be considered random.
Btw, I'm not convinced that this is the case.  In my experience, XML
parsers do, in fact, maintain document order.  But I'm willing to
develop the spec with the assumption that order might not be maintained.

Mike  

>-----Original Message-----
>From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp] 
>Sent: Wednesday, June 22, 2005 5:09 PM
>To: Drummond Reed; Wachob, Gabe; Lindelsee, Mike ; 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
>
>Is it not better to state that it should default to the document order
>than let the consuming application decide randomly? If the document
>order has some significance at all, we should exploit that 
>information. 
>
>Nat
> 
>
>-----Original Message-----
>From: Drummond Reed [mailto:drummond.reed@cordance.net] 
>Sent: Thursday, June 23, 2005 7:54 AM
>To: 'Wachob, Gabe'; 'Lindelsee, Mike '; '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
>
>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
>> 
>> 
>
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in
>OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
>