• Type: Bug
    • Resolution: Unresolved
    • Priority: Major
    • Component/s: Core
    • None
    • Hide

      Given the difficulty with providing a meaningful oslc:maxSize for non ASCII characters, and not wanting to break existing usage of oslc:maxSize, we could define a new property for an oslc:Property, say, oslc:maxSizeBytes, whose meaning relates to the number of bytes in the encoding of the server and/or its relational database. This would allow an OSLC client to validate the length of strings for OSLC servers using traditional relational databases.

      Show
      Given the difficulty with providing a meaningful oslc:maxSize for non ASCII characters, and not wanting to break existing usage of oslc:maxSize, we could define a new property for an oslc:Property, say, oslc:maxSizeBytes, whose meaning relates to the number of bytes in the encoding of the server and/or its relational database. This would allow an OSLC client to validate the length of strings for OSLC servers using traditional relational databases.

      The oslc:maxSize property is defined in OSLC Core 3.0 as:

      "For datatype properties whose type is xsd:string, oslc:maxSize specifies the maximum number of characters in the defined property value. The absence of oslc:maxSize indicates that either there is no maximum size or that the maximum size is specified some other way."

      Does this mean the number of:
      1) Unicode characters?
      2) Code points?
      3) Bytes in some encoding?
      It looks like the first is the intended meaning,.

      The issue is that many relational databases define VARCHAR(N) as a maximum of N UTF-8 encoded bytes (or a server encoding).

      The spec should be persistence agnostic and allow non-RDF-persistence that have well-defined size constraints, such as VARCHAR(N), to be described.

      The problem with the current definition is that an OSLC server that uses a relational database cannot meaningfully describe the oslc:maxSize of strings because the number of characters depends on whether each character is a 1, 2, 3, or 4 byte encoding - see http://tools.ietf.org/html/rfc3629.

            Assignee:
            James Amsden (Inactive)
            Reporter:
            davidhoney
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: