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: Our "priority"/etc attributes in extension/other elements...


Gabe et al,

Per our phone call yesterday, and a subsequent email I received from
Johannes Ernst on this topic, I believe the emerging consensus is for
attributes to be managed locally to each namespace within an XRDS document.

Here's how I'd sum up the rationale: an XRDS document processor, per the
extension architecture Gabe originally designed, should only process
elements in namespaces it understands. Anything else has a MustIgnore
behaviour.

With this being true, the processor will only process attributes within
those elements that it understands. Therefore the benefits of defining an
attribute used within the XRD namespace (or any other XML namespace)
globally would be very limited, because if a processor already understands
the elements of a particular namespace, then it will already understands the
attributes of those elements regardless of whether they are defined globally
or locally.

Net net: the only real "sharing" of attribute definitions within the XRD
namespace will be across the elements in the XRD namespace (which if
necessary can be done with attribute groups without requiring namespace
prefixes for the attributes). The same will be true for attributes of any
other XML namespaces used to extend an XRD or an XRDS document.

If this is true, then it is probably easiest for us and all these other
schema designers to define attributes locally to each element, because then
those attributes will not need to be namespace prefixed.

If anyone on the list disagrees, please post ASAP. Otherwise, silence =
consensus.

In which case, the last schema action item for the final Working Draft 10 is
to decide about putting the XRD priority attribute into an attribute group.
Since Gabe favored this on our last call, I'll make that change and post it
to the list for final review.

=Drummond 


-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Friday, March 17, 2006 1:42 PM
To: Drummond Reed; xri@lists.oasis-open.org
Subject: Our "priority"/etc attributes in extension/other elements...

Rethinking the global attribute thing yet again -- I guess I want to
confirm that the proposed change I made is definitely what is wanted. 

The proposed change means that the attributes such as "priority", etc
are local attributes. This means that they are defined by the element in
which they appear - they are not defined globally. 

Do we intend these attributes (e.g. "local", "select", etc) to mean the
same thing to all extension elements as well?  If so, perhaps we should
be using global attributes. The reason I say this is that the extension
schema are free to define whatever local attributes they want on
extension elements and they could easily define a "priority" attribute
which means something completley different than what we are defining the
local attribute "priority" to mean. 

If we don't assume that the "priority" (etc) attributes always mean the
same thing, even in extension attributes, then this isn't a problem. 

So, the question I have is what is the intent of the editors w/r/t
whether or not the "priority" attribute (et al) should *always* have the
same meaning, even if it appears in extension (or other) elements? 

   -Gabe

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net] 
> Sent: Wednesday, March 15, 2006 9:56 PM
> To: Wachob, Gabe; xri@lists.oasis-open.org
> Cc: 'Steve Churchill'
> Subject: RE: [xri] Yadis 1.0 is waiting on us
> 
> Gabe, Steve:
> 
> Thank you both for these - that completes all the action 
> items for Editor's
> Draft 09. I will post it shortly. All items that need 
> editor's review will
> be highlighted. Hopefully after tomorrow's TC call (4pm 
> Pacific) we'll wrap
> everything up and put out the final Working Draft 10.
> 
> =Drummond 
> 
> -----Original Message-----
> From: Wachob, Gabe [mailto:gwachob@visa.com] 
> Sent: Wednesday, March 15, 2006 3:00 PM
> To: Drummond Reed; xri@lists.oasis-open.org
> Subject: RE: [xri] Yadis 1.0 is waiting on us
> 
> In response to line 1586, its going to look like this (extensibility
> elements come after XRD-defined elements):
> 
> <XRD> 
>    <Service> 
>     ... 
>    </Service> 
>    <other:SuperService> 
>       <Service> 
>        ... 
>          <other:ExtensionElement>...</other:ExtensionElement> 
>       </Service> 
>    </other:SuperService> 
> </XRD>  
> 
> Line 1681 language:
> When XRI resolution is deployed to use HTTP URIs or other URIs which
> include DNS names, the accuracy of the XRI resolution response may be
> dependent on the accuracy of DNS queries. For those deployments where
> DNS is not trusted, the resolution infrastructure may be deployed with
> HTTP URIs that use IP addresses in the authority portion of HTTP URIs
> and/or with the trusted resolution mechanism defined by this
> specification. Resolution results obtained using trusted 
> resolution can
> be evaluated independently of DNS resolution results. While this does
> not solve the problem of DNS spoofing, it does allow the client to
> detect an error condition and reject the resolution result as
> untrustworthy. In addition, DNSSEC [DNSSEC] may be considered if DNS
> names are used in HTTP URIs.
> 
>    -Gabe
> 
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net] 
> > Sent: Tuesday, March 14, 2006 9:34 AM
> > To: xri@lists.oasis-open.org
> > Cc: 'Peter Davis'; 'Joaquin Miller'
> > Subject: [xri] Yadis 1.0 is waiting on us
> > 
> > Gang,
> > 
> > Note the following from the Yadis home page at
> > http://yadis.org/wiki/Main_Page:
> > 
> > "Yadis Specification Version 1.0 will be posted as soon as 
> Extensible
> > Resource Identifier (XRI) Resolution V2.0, Working Draft 10 
> > is posted by the
> > OASIS Technical Committee. We expect that working draft to 
> > have some changes
> > in the XRDS/XRD schemas; we do not expect those changes to 
> > affect the Yadis
> > protocol nor the Yadis document. Yadis Specification Version 
> > 1.0 will have
> > no other substantive changes from Yadis Specification Version 0.92."
> > 
> > Since they are announcing Yadis at PC Forum this week, I'd 
> > REALLY like to
> > get Working Draft 10 posted ASAP.
> > 
> > I'll call Gabe to see if he can do his review of the two 
> > options for the
> > updated schema today. For reference, they are posted at:
> > 
> > OPTION 1: 
> > 
> > http://www.oasis-open.org/committees/download.php/17123/draft-
> > XRD-cd02-v5.xs
> > d
> > 
> > This option explicitly calls out assignment of the priority, 
> > match, and
> > select attributes.
> > 
> > OPTION 2:
> > 
> > http://www.oasis-open.org/committees/download.php/17124/draft-
> > XRD-cd02-v5a.x
> > sd
> > 
> > This option makes the priority, match, and select attributes 
> > part of the
> > pool of local attributes that are used by the URI and 
> String patterns.
> > 
> > =Drummond 
> > 
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net] 
> > Sent: Monday, March 13, 2006 11:59 PM
> > To: xri@lists.oasis-open.org
> > Cc: 'Peter Davis'
> > Subject: [xri] Status report on XRI Resolution WD 10 ED 09
> > 
> > Per the minutes of last Thursday's call (below), I have now 
> > completed all my
> > action items. Wil has completed his and Steve has completed 
> > one of his two.
> > 
> > So Steve has one left, then the ball is in Gabe's court to 
> review the
> > proposed XRD schema updates (the two alternatives just 
> > posted) and then post
> > his recommendation to the other editors. Gabe also has two 
> other minor
> > action items.
> > 
> > See the updated TO DO list below for current status.
> > 
> > As soon as I receive these final action items, we'll be 
> ready to post
> > Editor's Draft 09, followed by the final Working Draft 10.
> > 
> > =Drummond 
> > 
> > 
> > 
> > *** TO-DOS FOR EDITOR'S DRAFT 09 OF WORKING DRAFT 10***
> > 
> > *** STEVE ***
> > 
> > !!!DONE!!! ### Line 1233 - Section 8 - Proof this whole 
> section and if
> > necessary
> > suggest text for this section or Appendix H to make it easier 
> > to understand
> > the matching/selection rules.
> > 
> > ### Appendix C - Example API - Send Drummond a draft in Word
> > 
> > 
> > *** GABE ***
> > 
> > ### Line 1586 - confirm that the XML example is legal or fix 
> > this section if
> > not
> > 
> > ### Line 1671 - Draft the new proposed text for this 
> section, send to
> > Drummond (or the list) in email or a Word doc
> > 
> > ### Second draft of updated XML schema after received from Drummond
> > 
> > 
> > *** WIL ***
> > 
> > !!!DONE!!! ### Line 1302 - Send Drummond the reference(s) 
> > needed to specify
> > how Unicode
> > case insensitivity should be done (note that Wil completed 
> > this before I
> > completed the minutes ;-)
> > 
> > 
> > *** LES ***
> > 
> > ### Third draft of updated XML schema.
> > 
> > 
> > *** PETER ***
> > 
> > ### Line 1021 - Confirm if SAML Name attribute value is correct
> > 
> > 
> > 
> > *** DRUMMOND ***
> > 
> > !!!DONE!!! ### Line 178 - Draft text and diagrams
> > 
> > !!!DONE!!! ### Line 278 - Add trust=https+saml option
> > 
> > !!!DONE!!! ### Add Section 6.3 on HTTPS+SAML
> > 
> > !!!DONE!!! ### Line 1473 - Renumber error codes
> > 
> > !!!DONE!!! ### Line 1610 - Add reference to RCC 2045
> > 
> > !!!DONE!!! ### Line 1643 - Find wording from SAML to acknowledge
> > 
> > !!!DONE!!! ### Line 1782/Appendix A - do first draft of 
> > updated XML schema
> > (Gabe second
> > draft, Steve/Les/Wil third)
> > 
> > !!!DONE!!! ### General - Add someplace the rationale for the 
> > refs parameter,
> > i.e., explain why a proxy resolver might have a no-refs policy.
> > 
> > 
> > *** POSTPONED UNTIL AFTER WORKING DRAFT 10 (UNASSIGNED) ***
> > 
> > Appendix C & D - Media Type definitions
> > 
> > Appendix F, G, H - Examples of generic res, SAML trusted res, 
> > and service
> > endpoint selection
> > 
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > 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_workgr
> > oups.php 
> > 
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > 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_workgr
> > oups.php 
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> 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_workgr
> oups.php 
> 
> 



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