Re: issues with BLD0921 (part 1 of n)

> 
> 
> - The first two paragraphs of the Overview say several things that I
>   don't think are true.  They can probably just be dropped.  We really
>   don't know how dialects fit together, not all dialects will extend BLD
>   (I assume that line is left over from when it was Core), and I'm
>   pretty sure that dialects (like BLD) don't have "a syntax" but
>   actually have multiple syntaxes.

Thanks Sandro. These pars have now been tightened.

> - The I in IRI stands for "Internationalized" not "International"
>   (thoughout the document).  This should be a reference to RFC 3987.

Done.

>   At
>   some point, we'll need to figure out a format for references in the
>   Wiki.  Maybe a Wiki link to a page with reference details, like
>   ["Ref/IRI"], and wiki-tr will build the appropriate bibliography?   
> 
> - "The central part of RIF is its Condition Language" bugs me a little.

This is how it is envisioned at this point. We'll know better when other
dialects are fleshed out.

> 
> - "but dialects that extend the BLD can and will support polymorthic
>   symbols"   Let's drop that "and will" -- we can't promise anything.

this wording has now been improved.


> - In the overview and later, I think "Presentation Syntax" was the
>   consensus term for the human-readable concrete syntax.   I'd like to
>   see that term used more in this document.   The text as is suggests
>   the XML syntax is not a concrete one.   It should be suggesting we
>   have two concrete syntaxes, the Presenation Syntax and the XML Syntax.

Yes. I changed this throughout, but I deleted this whole par about the
different syntaxes from the overview. There were flaky statements there and
a similar paragraph at the beginning of the syntax section does a better
job now.

> - In 2.1, and elsewhere, there are editorial comments like "In a later
>   draft, positive RIF conditions..."   Those should be set aside from
>   the text that's supposed to stay in the draft -- maybe using a color,
>   or just "EDITOR'S NOTE:" at the start of the paragraph.

fixed.

> - The explanation of signatures reads well, but it's still very, very
>   challenging.  Maybe it can at least include reference to works that
>   will help people understand it?  Maybe even in this pre-split draft we
>   can indicate which sections of the signatures discussion need to be
>   understood by people implementing BLD translators?  One of the parts
>   that's really hard for me is the distinction between signature names,
>   signatures, and signature expressions.  I can't really keep them
>   straight.    The actual examples do make sense to me -- maybe if one
>   of them were worked through in more detail, showing the roles of the
>   signatures, signature names, and signature expressions?   Or maybe
>   some of those distinctions can go away?

I did not do anything here yet, but will try to improve.


> - The only reference I've been able to find for "fully striped" is
>   "Normal Form Conventions for XML Representations of Structured Data",
>   where it's called "Alternating Normal Form", but it's still a useful
>   reference.  http://www.ltg.ed.ac.uk/~ht/normalForms.html

Should be explained. I added a TODO there.

> - This is about naming conventions, not BLD0921, but since it's in this
>   part of the text, I'll say here that the sentence :
>      'The 'Exists' formula is an "existential formula", which in
>      Horn-like conditions is the only quantified formula in in later
>      conditions may be complimented with the "universal formula"'
>   is one of those which, as an object-oriented designer, says to me very
>   strongly that the class should then be called 'ExistentialFormula' or
>   'Existential'.   (If you explain a term by saying it is something
>   else, that's usually a sign that you should just use the 'something
>   else' as the term.)


"Exists" is so common that you will hard time convincing people, I am afraid.


> - Why require one or more variables in an Exists?  In particular, the
>   Horn syntax requires a Forall/Universal, so it must allow zero
>   variables.   I think Exists should allow zero variables.

Yes, this is a leftover from earlier stuff. We are likely to change this to
0 or more.

> - Language like "is assumed to be", in "The length of the list of Var of
>   the declare property (role) of the Exists class is assumed to be 1 or
>   more" is, I think, quite confusing for a specification.  I think "must
>   be" is what we want.

Stella also mentioned this. Fixed.


> - In 2.1.3 (and other places), we shouldn't have text like "The
>   following is a possible XML-serializing mapping...".  The main text
>   should use crisp normative language about what must be done, and
>   material that says how "drafty" the text is should be in an EDITOR'S
>   NOTE about it, or something.  For example
> 
>         EDITOR'S NOTE: The XML syntax for BLD presented here is just one
>         proposal the Working Group is considering, and may be referred
>         to as "XML Syntax Strawman 1".  It is presented here to get
>         feedback on this strawman and to give readers an idea for the
>         kind of information will be presented in this section.

I included a version of the above statement and tightened the language a bit.


	thanks
	  --michael  


>   I say that as an example, since hopefully in the next draft the XML
>   syntax will actually have been agreed upon.
> 
> That's it, so far.
> 
>      -- Sandro
> 
> 
>

Received on Tuesday, 25 September 2007 03:05:56 UTC