RE: [xri] Yadis 1.0 is waiting on us

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

Gabe,

I suspected you'd come back with this range of options. That's the deal with
XML schema -- it's just a plethora of choices.

So let me spin this back around. You are the original architect of the
extensibility design of the XRDS and XRD schemas. Here's what I consider the
design goals for the updated schema:

#1: to preserve the namespace/extensibility architecture you worked out (and
which Yadis is already using).

#2: to make it easy for developers to produce and consume XRDS and XRD
documents without having to know/understand complex namespace rules (e.g.,
Victor's comments).

#3: to enforce the XRD element and attribute requirements of Working Draft
10 ed 09 (which I believe are all reflected in both of the versions I
posted).

Given those goals, can you come back with your recommended schema? 

My personal feedback is that I'm happy to go to RelaxNG and make that the
normative schema if you think that's best. I'm also willing to live with
namespace-qualified attribute names if we agree that's best.

Also, if you want to discuss via phone, just buzz me.

=Drummond 

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Tuesday, March 14, 2006 11:20 AM
To: Drummond Reed; xri@lists.oasis-open.org
Cc: Peter Davis; Joaquin Miller
Subject: RE: [xri] Yadis 1.0 is waiting on us

Drummond-
	I think the XSD you have is broken with respect to what you want
to do -- unless I am not quite following what you want to do. 
	The attributes, as you have defined them, are "global
attributes" in the XSD, which means that they are only usable through
explicit namespace qualification in conforming documents. Thus:

<Service xrd:priority="1"> is LEGAL
<Service priority="1"> is NOT

	That's ugly, in my estimation. This is a limitation of WXS - WXS
has no way of defining a "local" attribute for global use by any element
because WXS always has the concept of defining global things (elements,
attributes, attributegroups, etc) within a specific namespace - the
*only* exception is local attributes defined within the context of a
surrounding element (which is the modal case, typically). 

	I would note that because RelaxNG is pattern based, and is not
focused on defining names within a namespace,  it does not suffer from
this limitation. 

	There are a couple of workarounds:

1) Define the priority/match/etc attribute for each element that might
have the specific attributes and define those attributes locally for
each element. All extension elements would have to do this same work and
define those same attributes. 

2) Live with the namespace qualification of the attributes. This is
probably the most conventional way to do things. (My first choice)

3) Don't define the attributes in the WXS (they would still be legal
under a "##local"-namespace attributegroup - I think you'd have to
change the "otherattribute" production or add a "localattribute
production). Leave their defintion to the text of the spec.

4) In addition to #3, you could also specify the RelaxNG schema so there
is some machine parseable conformance testing. (This would actually be
my second choice behind #2) 

5) Lose the WXS because its painful, overkill and underkill for what we
are doing and go to RelaxNG only. (This would be my third choice - its
definitely the cleanest for us. RelaxNG is nice because it allows one to
more easily conform to Postel's law - "be conservative in what you do,
be liberal in what you accept from others". You can actually apply
multiple RelaxNG schema to different parts (and in combo with schematron
as well).

	#5 would be my first choice, but in the interest of speed and my
lack of time, I'm not pushing it. 

	I actually haven't looked further into the current XSD options
-- want to make sure you understand what you are currently doing. 

    -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_workgroups.php