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

From: "Rob Enns" <[email-masked]>
Date: Wed, 18 Jan 2006 14:44:12 -0800

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

xs:string is unconstrained by default, which (I think) is the
same thing as minLength="0" and maxLength="unbounded".

> 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 don't see any use for a zero length one of these, but I agree this
is a CLR and we should be firm on the introduction of CLRs. In this
case I suggest we let these stand as xs:string's.

> 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).

Sounds like a good change, I'll update -11 with this change.

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: Wed, 18 Jan 2006 15:21:03 -0800

>case I suggest we let these stand as xs:string's.

Okay - This will be interesting. 
IMO, the law of unintended consequences is going to bite us later, but 
we will see...

Personally, I would rather have a CLR that is consistently supported 
across all devices
than a unbounded type that few implementations support in the same way.

>Sounds like a good change, I'll update -11 with this change.

Andy