Re: [BLD] ACTION-

Boley, Harold wrote:
> Axel,
> 
> Thanks, I have meanwhile addressed these:
> 
> http://www.w3.org/2005/rules/wiki/index.php?title=BLD&diff=10052&oldid=9
> 999
> 
>> * Appendix 10
>>
>> similar to the Examples, the text should not be in fixed width font.
> 
> I removed the surrounding <pre> ... </pre>, so links, including to RFC
> 3023
> by IETF, became activated. The style is now as it is in such IETF
> documents.
> 
> Harold

All changes look good, only in my browser Appendix 10 still appears all 
in fixed width fonts (in blocks now), is that intended so?

Axel

> -----Original Message-----
> From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
> On Behalf Of Axel Polleres
> Sent: June 2, 2009 10:24 PM
> To: kifer@cs.sunysb.edu
> Cc: Public-Rif-Wg (E-mail)
> Subject: [BLD] ACTION- 
> 
> Here a summary on how my comments on BLD were addressed.
> I think the last couple of things should be easy to implement....
> 
> this completes action http://www.w3.org/2005/rules/wg/track/actions/823
> 
> 
> Some things which remain open:
> 
>> * Section 2 if it is not normative, then section 2.6 should be marked
>>  "(Informative)" explicitly.
> 
> 
> This wasn't addressed. I suggested to change:
> 
> 
> 2.6 EBNF Grammar for the Presentation Syntax of RIF-BLD
> 
> to
> 
> 2.6 EBNF Grammar for the Presentation Syntax of RIF-BLD (Informative)
> 
> 
>> * Section 2.1
>>
>> 'Const', 'Var' could be linked to the respective productions in the 
>> EBNF.
>>
>> Remarks: Would it make sense to change 'Names' to 'ArgNames' in the 
>> EBNF (independently of the previous point) and XML syntac or - vice 
>> versa - not to speak about the set  <tt>ArgNames</tt> but use 
>> <tt>Names</tt> instead?
> 
> was not addressed, but well, was only meant as suggestion.
> 
> 
>> Change: reference "Section Constants and Symbol Spaces" to "Section
>> Constants, Symbol Spaces, and Datatypes", this occurs several times.
> 
> has not been addressed, this reference is not the subsection where the 
> shortcuts are explained. either refere generically to Section 1 (Section
> Constants, Symbol Spaces, and Datatypes) or to the subsections of 1.2
> 
> 
>> * Appendix 10
>>
>> similar to the Examples, the text should not be in fixed width font.
> 
> has not been addressed yet.
> 
> 
> 
> Some more things in reply to Michael's notes on the review:
> 
> Michael Kifer wrote:
>> Thanks Axel for your detailed review. We applied most of your 
>> suggestions.
>>
>> Just few brief notes:
>>
>> 1. List (1|2) = 1 is unsatisfiable because the image of Ilist is 
>> disjoint from the data types. 
> 
> ok, had overlooked that I guess.
> 
>> Is there something in the definition 
>> that makes it seem as if this is satisfiable?
> 
> no then.
> 
>> 2. Abridged notation. As far as rif's presentation syntax is 
>> concerned, this is abridged notation (and CSMA even wants it to be 
>> marked non-normative). If you have a better name for it - fine. 
>> Otherwise, it is quite descriptive.
> 
> I suggest to speak about "compact representation" of IRIs instead of
> "abridged representation", that is also compliant with the rest of the
> document where
> you speak about "compact IRIs" (BTW: URI should be changed consistently
> to IRI, or is there a particular reason why you speak about compact URIs
> instead of IRIs?)
> 
> 
>> 3. In several places (related to conformance) you proposed to replace
>>  T with DTS. Actually, T is not a DTS but a set of data types and 
>> symbol spaces. This mention of symbol spaces was sometimes missing 
>> and some times they were incorrectly called namespaces. I fixed that.
>>
> 
> ok.
> 
> 
>> 4. Reference to the complexity of unification of named arg terms when
>>  arg names can be nonground terms rather than constants.
>>
>> I don't know of such a reference, but it is pretty easy to see that 
>> it is likely exponential. It is similar to commutative and 
>> associative unification, which is known to be NP-hard. For instance,
>>  http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.49.8880 
>> Probably has a reduction from it (never tried to prove it, but seems 
>> quite simple). This is because bags (which are arguments to named arg
>>  terms) can be represented as terms that are composed using an 
>> associative and commutative function symbol.
>>
>> Anyway, given that there is no direct reference, I think it is hard 
>> to do what you suggested in a concise way.
> 
> Ok, let's leave this out and see whether we get comments.
> 
>> 5. Primitive data types. The name is probably not optimal. Better 
>> suggestions? I think simply "datatype" can be misleading because RIF 
>> does not define any means of composing data types, unlike XML schema.
>>
> 
> I understand this has been addressed.
> 
>> 6. rif:local's as external names. I agree that they make no 
>> conceptual sense. But do we really need to disallow them? Note that 
>> because of the definition of external schemas, local symbols used as 
>> externals won't cause any problems for whoever uses them. This is 
>> just weird, but not outrageous.
> 
> well, I think it is indeed weird, but if nobody supports the wish to
> disallow them, I am fine.
> 
>> On Fri, 15 May 2009 23:21:49 +0200 Axel Polleres 
>> <axel.polleres@deri.org> wrote:
>>
>>> attached.
>>
> 
> 


-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/

Received on Thursday, 4 June 2009 18:47:31 UTC