RE: JW22: datatypes

> First:
> It is explicitly stated that the data types appear as XML elements.
> The DTD is:
>     <!ELEMENT datatype  ANY >

The DASL spec. never provides a DTD entry for each individual data type
element.  I'd expect to see:

<!ELEMENT boolean #PCDATA>
<!ELEMENT strong #PCDATA>
<!ELEMENT int #PCDATA>
<!ELEMENT float #PCDATA>
<!ELEMENT datetime.tz #PCDATA>

This way if you ever decided to validate your XML, the validator wouldn't
complain that these elements are undefined.

> Second:
> I disagree that there should be a BNF for each data type,
> especially for datetime. I have seen other specs. that point
> out that a BNF for datetimes is really messy, and was
> therefore left out of the spec. It is not really up to
> DASL to define these formats anyway. They should be defined
> in some other spec. somewhere.

If you don't define the BNF, you will have no end of interoperability
problems.  It is a simple task to write converters from one datetime format
to another, far easier than trying to fix fielded software to address
interoperability problems.

Plus, developing the BNF descriptions isn't that tough.  Here's a start:

boolean = "0" | "1"
integer = 1*DIGIT    ; DIGIT is defined in RFC 2068, section 2.2
float = 1*DIGIT ("." 1*DIGIT) (("e"|"E")1*DIGIT)
date-time            ; defined in RFC 2518, section 23.2

> Third:
> Specification of the natural language for properties
> (DAV:propdesc) and string literals is only necessary if
> more than one is involved. If the repository is all in
> the language you wanted and got by content negotiation,
> we don't want to mess up the syntax with anything
> additional. However, for the case where the repository
> has documents in multiple languages, maybe it would
> be a good idea for propdesc to return the natural language
> for string properties along with the other information.
> As far as specifying the natural language the string
> literals were composed in, that would provide another
> error check. Or, we could just assume we know what it
> is from the natural language of the property involved.
> If we want to specify it for string literals, it
> obviously should be added to the attribute list for
> literals.

It may be that the language only needs to be returned with the search
results, not submitted with the search request.

- Jim

Received on Thursday, 24 June 1999 20:37:14 UTC