Re: On ISSUE-6 (invalid values in @datatypes cause plain literals to be generated)

Hi Shane,

Ah...does this perhaps explain why everyone disagreed with me about
mixing terms and prefixes -- the belief that you had to discern
between patterns before you even began to match?

I think it's much simpler than that.

In my mental model (as you know) a prefix and a term are one and the
same. They are defined as a mapping, and it's merely the place they
are used that distinguishes them.

The algorithm to implement this goes as follows:

* does the value contain a colon?

  * COLON: does the /prefix/ *exactly* match a defined mapping?

    * MAPPING: we have a CURIE, and the resulting URI is the suffix
appended to the mapped URI;

    * NOMAPPING: the resulting URI is the value itself (absolute).

  * NOCOLON: does the /value/ *exactly* match a mapping?

    * MAPPING: we have a token, and the resulting URI is the mapped URI;

    * NOMAPPING: the resulting URI is the value itself (relative).

That's it. There's no need to worry about whether something looks like
a term or a relative URI or whatever. The entire thing is based on
whether a mapping exists for the full value or its prefix (depending
on the presence or absence of a colon).

Going over old ground here I realise, but merging terms and prefixes
really does seem very simple and natural to me, and in my view solves
all of the problems currently under discussion.

Regards,

Mark

On Mon, May 17, 2010 at 2:53 PM, Shane McCarron <shane@aptest.com> wrote:
> FWIW it was my *intent* that we only permit absolute URIs.  I remember that
> we debated this, I don't remember when nor why.  However, just from a
> processing / parsing perspective, I think something evaluating an attribute
> that takes the type TERMorCURIEorURI would work like this:
>
> Does the value match the production for a term?  If so, evaluate it as a
> TERM (which might mean it gets thrown away) and stop.
> Does the value match the production for a CURIE?  If so:
>
> Is there a matching in scope prefix mapping?  Yes, then expand the CURIE.
> No?  Treat it as an absolute URI
>
> In other words, in my mental model for this AND in my implementation, a
> relative URI would never get treated as valid because a relative URI doesn't
> have a prefix.  Remember, the ONLY reason we added this rule was to
> accommodate absolute URIs.
>
> Regardless, if you all want to try to support relative URIs as well... I
> guess that's okay, but I agree with others that there is not really a use
> case I can see and I think it makes processing more difficult, introduces
> new, interesting, and ugly edge cases, and will make document authoring even
> more error prone.
>
>
> On 5/17/2010 7:39 AM, Mark Birbeck wrote:
>
> Hi Toby,
>
>
>
> This is precisely the specific problem that should force us to disallow
> relative URIs. If people think they can use relative URIs, they'll use
> things like datatype="foo.html", but that will be interpreted as a
> term, as "." is allowed in NCNames. The rules on when something is
> interpreted as a relative URI reference and when it's interpreted as a
> token would be confusing to authors.
>
>
> Well...we actually already have the rule. If it's not a term, and it's
> not a CURIE then by definition it's a URI  -- absolute, relative,
> whatever.
>
> I think that's actually quite straightforward.
>
> Regards,
>
> Mark
>
>
> --
> Shane P. McCarron                          Phone: +1 763 786-8160 x120
> Managing Director                            Fax: +1 763 786-8180
> ApTest Minnesota                            Inet: shane@aptest.com
>
>

Received on Monday, 17 May 2010 15:48:39 UTC