| RE: [higgins-dev] Model: Split EntityUDI into two types? |
|
I agree that a relative entity UDI can be
a string. But I’d strongly suggest we follow URI architecture so there very
clear rules about when an entity UDI is absolute or relative. Why would we want
to reinvent URIs? Even XRI (which went down that road in its early days)
realized the error of its ways and adopted URI architecture. So you can
unambiguously tell if a XRI is absolute or relative just as you can
unambiguously tell if a URI is absolute or relative. (RFC 3986 explains how to
handle the small set of possible exceptions allowed by its ABNF.) =Drummond From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Markus Sabadello Also, my view is that an
entity UDI can never be unambiguously absolute or relative, because you can't
make any assumptions about a relative entity UDI. CPs should be free to use
whatever they want to identify their entities within their contexts, therefore
a relative entity UDI can be any string. On Wed, Jun 18, 2008 at 9:30 AM, Jim Sermersheim <jimse@xxxxxxxxxx> wrote: On #1, how does one make this
determination? I mean, if I presented some string to you and said:
"this is a UDI" what logic do you perform to determine whether it's
relative or absolute? We talked about #2 on the IRC. Markus
suggested that a relative entity UDI could be an unencoded entity ID whereas an
absolute entity UDI would need to have its "entity ID" part encoded. This
seemed like a good solution.
Jim, two issues: 1) All currently contemplated
UDIs (which all derive from URIs) are unambiguously absolute or relative. So,
if you want, you can always determine this from the UDI value itself. 2) The difference between
a relative UDI and a string is that a relative UDI requires encoding as a valid
URI, whereas strings can contain spaces and other non-legal URI characters. My own POV is that this
encoding is: a) trivial, and b) deterministic transformation in both
directions, so it would indeed be easiest to just have the EntityID be a UDI
and be done with it. That's also "the Web way". =Drummond From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx]
On Behalf Of Jim Sermersheim Sent: Tuesday, June 17, 2008 2:08 PM To: Higgins dev <higgins-dev@xxxxxxxxxxx Subject: [higgins-dev] Model: Split
EntityUDI into two types? Paul, Right now the 1.1 model allows a
higgins#entityId to have values of types: higgins:EntityUDI, and xsd:string. If the value is of type
higgins:EntityUDI, there's really no way of knowing whether it's relative or
absolute. Could we instead make
higgins#entityId allow values of higgins:RelativeEntityUDI and
higgins:AbsoluteEntityUDI? If CP's are going to be able to
dereference entity UDI values, they'll have to know whether the values are
relative or not. If we did this, we wouldn't
actually need xsd:string to be one of the allowed value types. As I
understand it, a relative entity UDI would be exactly the same as our old-style
entityID strings. So since they are syntactically and semantically
equivalent, there shouldn't be a need for xsd:string. Jim
|