RE: proposal text for 5741

Thanks, that concreteness helped.  I see what you are on about with [a], 
although I think we still _can_ implement the agreed-to resolution.  It's 
a question of which is uglier, to create something a coder could use 
directly (pretty much what we have now) that intermingles content with 
various normative origins, or create something a bit uglier for coders but 
clearly separating what SML is inheriting vs imposing (and thus head off 
accusations that we are attempting to re-specify things normatively 
covered elsewhere).  I'm attaching a draft of what the latter might look 
like, so people can make a more informed choice.  I have no strong 
preference, although I do worry given past discussions that intermingling 
them is going to set off the more W3C Rec-literate reviewers.  I guess 
that means mild preference for the format in which I drafted it, that gets 
a clear separation and explicitly kneels before the appropriate altars.

Comments on your diff:
> sentence about the computation of [base URI] being app-defined
I think we want to say SML is not constraining it, rather than 
impl-defined.  I took that approach in my draft.  I think it gets us to a 
similar place, without imposing a requirement on SML model s/w in general 
to document its internals.  Until it is serialized for interchange, it 
seems like it's just none of my business how the impl handles base URIs.
> update in 2.a.ii.B
You need to back that out.  Retrieval actions are in the URI scheme specs, 
not in the URI RFC.  In fact, the latter explicitly defers to the former.
> fragment component complies with the smlxpath1()resolves XPointer scheme
This would need to be hit again for 5543 bare names.  Bare names according 
to [XPointer FW] are not scheme-based.  
http://www.w3.org/TR/2003/REC-xptr-framework-20030325/#syntax , first 
production is an alternative between shorthand (barename) and 
scheme-based.
> Editor's draft:       ...obtained by applying the fragment component to 
the root element of D
> 5741 draft:   ...obtained as defined in section 4.3.1.1 smlxpath1() 
scheme scheme
I guess, for me, the editor's draft version is fine.  Because we're not 
intending to rewrite existing specs, the URI RFCs defer to the media type 
for fragment handling; the XML media type fragment handling spec is 
[XPointer FW]; latter tells you how to handle instances of any XPointer 
Scheme-based fragment (i.e. according to the scheme's definition), which 
is exactly what you're saying given SML's constraints on valid fragment 
syntax.  My guess is that your version runs a higher risk of triggering 
some reviewers' "you're re-write specs that's not allowed" knee-jerk 
reaction.  In my draft I explicitly bowed in the direction of media type 
for fragment handling, just to reduce those odds further.

Best Regards, John

Street address: 2455 South Road, P328 Poughkeepsie, NY USA 12601
Voice: 1+845-435-9470      Fax: 1+845-432-9787



From:
Kumar Pandit <kumarp@windows.microsoft.com>
To:
John Arwe/Poughkeepsie/IBM@IBMUS, "public-sml@w3.org" <public-sml@w3.org>
Cc:
Kumar Pandit <kumarp@windows.microsoft.com>
Date:
08/20/2008 09:02 PM
Subject:
RE: proposal text for 5741



Hi John,
Thanks for the feedback. Diff is attached. Changes are in section 4.3.1 
SML URI Reference Scheme.
 
[a]
The following is defined by our spec and is not in any RFC, therefore must 
remain normative:
1.    [base URI] property is used.
2.    Computation of [base URI] is app-defined.
3.    U is dereferenced to get target
4.    If target is not in current model then ref is unresolved.
5.    No fragment => root element
6.    If no smlxpath1() => unresolved (this will be updated for allowing 
shorthand pointer later).
 
[c]
This is subtle. Earlier we had uri#location-path and we applied the entire 
fragment (== location path xpath) to the root element. Now we have 
uri#smlxpath1(location-path), therefore we apply part inside ( ) to the 
root element after xpointer syntactical check.
 
 
 
From: public-sml-request@w3.org [mailto:public-sml-request@w3.org] On 
Behalf Of John Arwe
Sent: Wednesday, August 20, 2008 7:48 AM
To: public-sml@w3.org
Subject: Re: proposal text for 5741
 

a.  As stated is a tautology.  Which steps need to remain normative, and 
why, is needed. 
b.  Covered by http://www.w3.org/Bugs/Public/show_bug.cgi?id=5741#c1 so 
should be fine. 
c.  As stated looks recursive.  Best guess is that you mean (wrt Editor's 
draft) 4.3.1 item 2.c, but cannot be sure.  I don't see any obvious 
uri#location-path specificity in there, so I question whether or not I 
guessed right.  The proposed text would have to change again for the 
barenames resolution too, no? 

could we get a marked up draft (diff, doc change tracking, whatever)?  I'm 
not good at screen flipping and mental deltas, and we do have tools for 
that. 

Best Regards, John

Street address: 2455 South Road, P328 Poughkeepsie, NY USA 12601
Voice: 1+845-435-9470      Fax: 1+845-432-9787 

From: 
Kumar Pandit <kumarp@windows.microsoft.com> 
To: 
"member-sml@w3.org" <member-sml@w3.org> 
Cc: 
Kumar Pandit <kumarp@windows.microsoft.com> 
Date: 
08/20/2008 01:22 AM 
Subject: 
proposal text for 5741
 




The resolution was to make the relevant steps in “4.3.1 SML URI Reference 
Scheme” non-normative. When I started working on the bug, I realized 3 
issues: 
a.    we cannot make some of the steps non-normative because they need to 
remain normative. 
b.    we had agreed earlier to use the term ‘the applicable URI RFC’ 
instead of ‘RFC 3986’ explicitly for the SML URI scheme. 
c.    Item (c) was based on the earlier format of sml:uri (that is, 
uri#location-path). It needs to change to reflect support for smlxpath1(). 

  
I have captured the resultant text in the attached file. Please take a 
look to see if you are ok with it. If so, please reply to this email so 
that I can update the text before Thursday. If you do not you agree, 
please send your suggestions. 
  
 [attachment "5741-proposal.doc" deleted by John Arwe/Poughkeepsie/IBM] 
[attachment "5741-proposal.pdf" deleted by John Arwe/Poughkeepsie/IBM] 
[attachment "diff-sml.html" deleted by John Arwe/Poughkeepsie/IBM]