Subject: RE: Q: No max/ minMax length of anything?

From: "Rob Enns" <[email-masked]>
Date: Fri, 13 Jan 2006 11:31:56 -0800

> <Andy>
> We decided (and nobody objected) that the message-id attribute is 
> maxLength="4095".
> Other than that, all data types are constrained AFAIK.  We 
> don't control
> 
> the URL limits.
> </Andy>
> 
> Did we? It isn't in -10
> 
> <xs:attribute name="message-id" type="xs:string" use="required"/>

It will be in -11 (hey, NETCONF goes to 11!)

  <!--
    message-id attribute
    -->
  <xs:simpleType name="messageIdType">
    <xs:restriction base="xs:string">
      <xs:maxLength value="4095"/>
    </xs:restriction>
  </xs:simpleType>

Rob

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 15 Jan 2006 12:05:49 -0800

>      <xs:maxLength value="4095"/>

I think xs:string is minLength="0" and maxLength="unbounded" by default.
(Can somebody confirm this?)

Doesn't that mean that we need minLength="1" in some cases?

Here is Martin's list:

    confirm-timeout  is a positiveInteger (no upper bound)  (could e.g.
                          have been unsignedInt)
    error-app-tag  is a (unbounded) xs:string
    error-path  is a (unbounded) xs:string
    error-message  is a (unbounded) xs:string

I think allowing message-id to be zero-length is broken.

I also think the 3 error-* strings should have a minLength="1" facet.
I know this is a CLR, but IMO, I would rather these optional parameters
not be present in this case.  Operationally, I can't think of any value
zero-length strings will add to the debugging process.

I agree with Martin, and would like to change confirm-timeout to
a simpleType (base="unsignedInt" minInclusive="1").  The positiveInteger
base type is a string, not a number.  This requires much more processing
internally than unsignedInt.  positiveInteger has no upper bound,
but unsignedInt does (and 4 billion seconds is a long enough timeout).

>Rob

thanks,
Andy