| RE: [higgins-dev] Model: Split EntityUDI into two types? |
|
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 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
|