Re: [xri] RelaxNG schemas for XRI resolution

[John Bradley <jbradley@mac.com>]

Agreed for what its worth.  The potential for collision always  
bothered me.

=ve7jtb
On 25-Oct-07, at 2:23 PM, Tan, William wrote:

> I agree that we should not allow extension attributes that are no  
> namespace qualified, if for no other reason than to be able to tell  
> them apart from the "built-in" ones.
>
> =wil
>
> Gabe Wachob wrote:
>>
>> Besides the attribute extension and missing redirect attribute  
>> issues, I also realized that the “extension” attribute pattern in  
>> the original schema was wrong, I THINK.
>>
>> Here’s the thing – if we allow “extension” attributes – what  
>> attributes do we allow exactly?
>>
>> Do we allow **any** attribute, whether local or namespace  
>> qualified? What are your thoughts? My feeling is that you are  
>> asking for trouble if you start sprinkling around non-namespaced  
>> attributes as **extension* *attributes.. (its fine when they are  
>> in elements YOU define).
>>
>> So my preference I think is to allow only extension attributes  
>> that are namespace qualified, and NOT in the xrd/xrds namespaces  
>> (we don’t define **any** attributes that are namespace qualified  
>> with the xrd or xrds namespaces) . Anyone gotta problem with THAT?
>>
>> -Gabe
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> *From:* Gabe Wachob [mailto:gabe.wachob@amsoft.net]
>> *Sent:* Monday, October 22, 2007 6:18 PM
>> *To:* 'OASIS XRI TC'
>> *Subject:* [xri] RelaxNG schemas for XRI resolution
>>
>> I went ahead and threw together two RelaxNG schemas (one for XRDS,  
>> one for XRD). Please check carefully – this is a very rough cut  
>> and I had to guess at element ordering in many places.
>>
>> I note that in the document, there are a lot of places where  
>> attributes are referred to by qualified name – I missed in this in  
>> my last review, but I believe the XML schema and our decision was  
>> to make them **unqualified** - so in section 4.1, you wouldn’t use  
>> @xrds:ref, you’d simply use @ref
>>
>> Anyway here’s the two schemas cut n pasted in:
>>
>> xrds.rnc
>>
>> namespace xrds = "xrd://$xrds"
>>
>> datatypes xs = "http://www.w3.org/2001/XMLSchema-datatypes";
>>
>> anyelement =
>>
>> element * {
>>
>> (attribute * { text }
>>
>> | text
>>
>> | anyelement)*
>>
>> }
>>
>> start = element xrds:XRDS {
>>
>> attribute ref { xs:anyURI },
>>
>> anyelement *
>>
>> }
>>
>> xrd.rnc
>>
>> default namespace = "xrd://$xrd*($v*2.0)"
>>
>> namespace xrd = "xrd://$xrd*($v*2.0)"
>>
>> namespace saml = "urn:oasis:names:tc:SAML:2.0:assertion"
>>
>> namespace ds = "http://www.w3.org/2000/09/xmldsig#";
>>
>> datatypes xs = "http://www.w3.org/2001/XMLSchema-datatypes";
>>
>> datatypes rd = "http://relaxng.org/ns/compatibility/datatypes/1.0";
>>
>> start=XRD
>>
>> anyelementbody =
>>
>> (attribute * {text}
>>
>> | text
>>
>> | element * {anyelementbody} )*
>>
>> non.xrd.element = element * - xrd:* {
>>
>> anyelementbody
>>
>> }
>>
>> non.xrd.attribute = attribute * - xrd:* {text}
>>
>> # XRD Element
>>
>> # XXX Need to check order of the following
>>
>> XRD=element XRD {
>>
>> attribute xml:id {rd:ID} ?,
>>
>> attribute idref {rd:IDREF} ?,
>>
>> attribute version { "2.0" } ?,
>>
>> Query ?,
>>
>> Status ?,
>>
>> ServerStatus ?,
>>
>> Expires ?,
>>
>> ProviderID ?,
>>
>> (Redirect | Ref) ?,
>>
>> LocalID *,
>>
>> EquivID *,
>>
>> CanonicalID ?,
>>
>> CanonicalEquivID ?,
>>
>> Service *,
>>
>> element saml:Assertion {anyelementbody} ?,
>>
>> non.xrd.element *
>>
>> }
>>
>> Query=element Query {
>>
>> non.xrd.attribute *,
>>
>> text
>>
>> }
>>
>> statuspattern = attribute code {xs:integer},
>>
>> attribute cid { "absent" | "off" | "verified" | "failed" },
>>
>> attribute ceid { "absent" | "off" | "verified" | "failed" },
>>
>> text
>>
>> Status=element Status {
>>
>> statuspattern
>>
>> }
>>
>> ServerStatus = element ServerStatus {
>>
>> statuspattern
>>
>> }
>>
>> Expires = element Expires {
>>
>> xs:dateTime
>>
>> }
>>
>> Redirect = element Redirect {
>>
>> attribute priority {xs:integer}?,
>>
>> xs:anyURI
>>
>> }
>>
>> Ref = element Ref{
>>
>> attribute priority {xs:integer}?,
>>
>> xs:anyURI
>>
>> }
>>
>> ProviderID = element ProviderID {
>>
>> xs:anyURI
>>
>> }
>>
>> # not specifying requirements for saml:Assertion - maybe we should?
>>
>> LocalID = element LocalID {
>>
>> attribute priority {xs:integer},
>>
>> xs:anyURI
>>
>> }
>>
>> EquivID = element EquivID {
>>
>> attribute priority {xs:integer},
>>
>> xs:anyURI
>>
>> }
>>
>> CanonicalID = element CanonicalID {
>>
>> xs:anyURI
>>
>> }
>>
>> CanonicalEquivID = element CanonicalEquivID {
>>
>> xs:anyURI
>>
>> }
>>
>> Service = element Service {
>>
>> attribute priority {xs:integer}?,
>>
>> ProviderID?,
>>
>> LocalID *,
>>
>> Type *,
>>
>> Path *,
>>
>> MediaType *,
>>
>> (URI+|Redirect+|Ref+)?,
>>
>> element ds:KeyInfo {anyelementbody}?,
>>
>> non.xrd.element *
>>
>> }
>>
>> URI = element URI {
>>
>> attribute priority {xs:integer}?,
>>
>> xs:anyURI
>>
>> }
>>
>> selection.attributes = attribute match {"any" | "default" | "non- 
>> null" | "null" },
>>
>> attribute select { xs:boolean}
>>
>> Type = element Type {
>>
>> selection.attributes,
>>
>> xs:anyURI
>>
>> }
>>
>> Path = element Path {
>>
>> selection.attributes,
>>
>> xs:string
>>
>> }
>>
>> MediaType = element MediaType {
>>
>> selection.attributes,
>>
>> xs:string
>>
>> }
>>
>
>
> ---------------------------------------------------------------------
> 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

smime.p7s