RE: [Alan Babich comments on] draft-reddy-dasl-protocol-00.txt

My comments are interspersed.

Alan Babich

> -----Original Message-----
> From:	Jim Davis [SMTP:jdavis@parc.xerox.com]
> Sent:	March 14, 1998 6:55 PM
> To:	www-webdav-dasl@w3.org
> Subject:	RE: [Alan Babich comments on]
> draft-reddy-dasl-protocol-00.txt
> 
> At 06:18 PM 3/13/98 PST, Babich, Alan wrote:
> >First, if I understand what you've done, you've chosen 
> >prefix notation.
> 
> Glad you like it, but we don't deserve any credit for it, since it was
> forced on us by our choice of XML.  
	[Babich, Alan]  
	Yes, now that you mention it, the prefix notation is the most
	natural and economical in XML due to the begin/end bracketing
	structure of the XML notation. I've though a bit about how to
express 
	infix and postfix notation in XML. It seems to me one would have
to
	use extra enclosing tags, which is silly, complicates things a
bit, and
	adds no value.

> If you're new to XML, some good
> references are 
>  http://www.sil.org/sgml/xml.html
>  http://www.w3.org/TR/PR-xml
> 
	[Babich, Alan]  
	Thanks for the references. I got a couple of other URL's and
started
	reading the XML spec. At first, I was confused by the element
	declarations in the proposal, e.g., section 5.4, "The select XML
	Element". Then I thought they were incorrect. Now I think that,
	while they do not look exactly like EBNF productions, they
	give the syntax for something. Learning XML straight
	from the spec. is harder than I expected. I'm learning XML as
	fast as I can make time for it, so that I can communicate
	with the group better, and so that I can critique proposals
	better and make good proposals for DASL.
>  
> Also if you look at the current WedDAV spec it includes the full DTD
> for
> WebDAV, so you can use the DTD instead of BNF it will help the
> discussion.
> 
	[Babich, Alan]  I'll do that as soon as I can get to it.

> Next, you propose to introduce operators that are explicitly typed.  
	[Babich, Alan]  Not exactly. I just used a systematic naming
convention
	from which you can infer the type of the operands, assuming that
	all operands have the same type. You have to call the operators
	by some name, and, if you believe as I do, that implementations
	would be simplified by strongly typing the operands of each
	operator, you may as well indicate the type of operands
	as a variation on the name of the operator. It turns out that
	it is quite reasonable for the operators in the current proposal
	to all be of the same type.

> This
> may be a good idea in the long run but I see two problems with the
> particular approach you've suggested.
> 
> First, there's no mechanical way to tell what datatype each operator
> accepts.  It's not okay for programs to guess by parsing the name,
> e.g.
> inspecting  gt_integer and noticing the "integer" after the
> underscore.
	[Babich, Alan]  I did not intend for programs to parse the name
	of the operator to get the types of the operands.
	I intended for the types to be known by reading the spec.
	Also, the result type and argument types could be available at
run
	time. (If I understood XML better, I could write some for you.)
	This would probably a requirement for at least the
	operators that are NOT required to be implemented in all
	implementations, and, possibly, should be a requirement
	for all operators, required or not. I did not give a syntactic
	proposal to describe operators in XML, because I don't
	know XML well enough yet.

> Second, what would you do for operators that take operands of more
> than one
> type, e.g. the (perhaps contrived) "length_lt" operator which take a
> string
> and an integer and returns true if the string's length is less than
> that of
> the integer.  (Of course in a real programming language one would
> write (lt
> (length str) int) but we have only a query language here.)
	[Babich, Alan]  For all operators, not just operators that take
	operands of more than one type, I intended that we explicitly
give
	the type of each operand in the description of the operator.
	I intended that the first argument could be type A, and the
second
	argument could be type B, etc. I had also envisioned giving
	a minimum and maximum number of operands (where
	the maximum and minimum could be the same). One possible value
	for the maximum-number-of-operands field would be "unboundedly
	many". For the unboundedly many case, the type of all operands
	beyond the last one that is explicitly given, is by convention
the same
	as the last type explicitly given. For example, for AND and OR,
	minimum number of operands is 2, maximum is "unboundedly many",
	the type of the first operand is Boolean, the type of the second
	operand is Boolean, and all subsequent operands must be Boolean,
	because the last type explicitly given (i.e., the type of the
second operand)
	is Boolean.

	For the case of your "length_lt" operator, the type of the first
operand
	is explicitly given as string, and the type of the second
operand is integer.
	The minimum number of operands is 2, and the maximum is 2. The
result
	type is Boolean.

	However, as you pointed out, that probably wouldn't be a good
operator to
	define. It would be better design to define a "string length"
operator
	(a la "strlen") that took a single operand of type string, and
returned
	an integer, and to define the six standard relational operators
where
	both operands are integers (lt_integer, etc.). We would expect
to get
	get more mileage out of these operators than the "length_lt"
operator.


> The other syntactic simplifications you propose seem very sound to me.
> 
> I'd be grateful to have your comments on the proposal for query schema
> definition.  We don't have access to the powerful self-description of
> DMA
> in DAV, but I still hope to approach it when we can.
> 
> Best regards
> 
> Jim

Received on Tuesday, 17 March 1998 15:20:20 UTC