Add TURF support for object handles in resource declarations.

Description

Preliminary support for object handles was added to TURF already:

That should be the same as:

But apparently support for types was not added in this form, e.g.:

The code should be refactored as needed, and the TURF specification production rules, too. For example, should we support the following? Probably:

Environment

None

Activity

Garret Wilson 
January 20, 2019 at 1:12 AM

Well it turns out there was a little gotcha in the parsing: the handles true and false are overloaded in TURF with the Boolean representations of the same name. So before parsing an object it seems we'll have to parse the handle; if it is true and false, the Boolean representation wins—or put another way, the handles true and false and not allowed anywhere an object can be (which means technically they could be used as a property tag reference).

Because we have to parse the handle before parsing the object, it seems the grammar is simpler if we say the _object_ production rule must begin with a *, making the _object_ production rule after the handle itself. Since the _object_ production rule stands on its own and has an optional type, it would be difficult in the grammar to say that an _object_ can come after a handle, but only if it has a type. Or the other way, to make the * of _object_ optional, would mean that the _object_ production rule would possible contain nothing.

So in short, it seems that with the handle before the optional _object_ production rule, it seems simplest in the grammar to require * in the _object_ production rule, which means that both foo and foo* would be allowed, just as we allow both |<https://urf.name/foo>| and |<https://urf.name/foo>|*.

Garret Wilson 
January 19, 2019 at 8:32 PM

On a separate note, "tag equivalent" might be a slightly more correct name for what is now being called a "tag reference".

Garret Wilson 
January 19, 2019 at 8:30 PM
(edited)

It's still uncertain whether we should support a handle with the object begin delimiter:

I guess the reasoning against it would be that a handle substitutes for the * object representation, so if there's a handle there's no need for something to indicate an object. The other reason is that it seems cluttered to allow foo: or foo*:, when both mean exactly the same thing.

On the other hand, we have to allow it if there is a type, even with a handle, e.g. foo*Bar. And the TURF idea of a "tag reference" says that a tag label |<https://urf.name/foo|> is equivalent to foo, which seems to indicate that both |<https://urf.name/foo>|* and foo* should be allowed.

Back on the first hand, though, remember that we're talking about a resource declaration, and that's not necessarily the same thing as a tag reference. There are places where tag references are allowed (e.g. a property), but no description is allowed. In fact the case could be made that a resource declaration is not a tag declaration at all, even though it contains a label or a tag in the same position, similar to a tag reference. In fact the current production doesn't even call it a tag reference in a resource description. So maybe it's best to consider the handle part of the object declaration, and prevent * with a handle unless followed by a type.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Priority

Created January 19, 2019 at 6:02 PM
Updated January 21, 2019 at 9:58 PM
Resolved January 21, 2019 at 9:58 PM