Re: [BLD] My comments on version dated 5/10

> A first general comment: overall, the document improved a lot. I am 
> impressed!

Good! I made some changes along the lines you suggested. Here are some
replies to other issues that you raised.

> - Since the signature stuff has no impact on either the presentation 
> syntax, XML syntax or semantics of BLD, couldn't we move that part of 
> the spec to a different place? That stuff is useful to people who will 
> extend BLD, not to people who will implement it, as I understand it, and 
> I am afraid that it might scare implementers away! If it cannot be 
> easily moved, maybe all the relevant paragraphs could be clearly 
> identified (e.g. boxed) and marked as non-required reading for 
> implementers or something like that?

For draft #3 we agreed to split the document. Not for #2.


> - The separation of the specification of the condition language between 
> a non-slotted and a slotted part is mostly historic, isn't it? It would 
> make the doc an easier reading if they were reunited.

Again, not for #2, as we discussed. Also, some people think there is value
in the separation, since it shows how more restricted dialects (frame-less)
can be defined.

> - In some examples, we have 2 different serialisation for the same 
> expression: how do we deal normatively with that? We could define a 
> normal form for RIF XML rules; or we could require that implementations 
> preserve the form of an expression, for round-tripping purposes (that 
> would be kind of difficult, though)

Can you point to these specifically? We need to fix that.

> - Organisation of the document: some sections are very long and contain 
> a lot of material. Couldn't they be cut into pieces? It would make it 
> easier to refer to material in the document.

Not for #2. Draft 3 will look very different, as I pointed out above.

> - sect. 2.1.1.1, subsect. "Symbol space", end of 1st par., "...we will 
> introduce a syntax for for defining prefixes for compact URIs.": is that 
> true? Is that something we really want to do? Same for "TO DO: Define 
> CURIES", by the way...

Why not? How else can we be self-contained as far as curies are concerned?


> - sect. 2.1.1.2, 5th par. ("We now give an EBNF...), but-last sentence, 
> "It is not intended to be used as a concrete syntax for a rule 
> language": add "RIF concrete syntax is the XML syntax for interchange"?

Here we are talking about  a concrete language for a rule language, not
about a RIF concrete language.




	--michael

Received on Wednesday, 10 October 2007 00:28:06 UTC