Subject: Re: [Ecrit] LoST schema omission

From: Andrew Newton <[email-masked]>
Date: Mon, 4 Feb 2008 12:08:21 -0500

On Jan 7, 2008, at 11:52 PM, Thomson, Martin wrote:

> The problem is that the "locationUsed" element (and all that is  
> related to its use) is not defined in the schema.

Yup.  That's a problem.

> div {
>  findServiceResponse =
>    element findServiceResponse {
> +      mapping+, locationValidation?, commonResponsePattern,  
> locationUsed?
> -      mapping+, locationValidation?, commonResponsePattern
>    }
>  listServicesResponse =
>    element listServicesResponse { serviceList, commonResponsePattern }
>  listServicesByLocationResponse =
>    element listServicesByLocationResponse {
> +      serviceList, commonResponsePattern, locationUsed?
> -      serviceList, commonResponsePattern
>    }
>  getServiceBoundaryResponse =
>    element getServiceBoundaryResponse {
>      serviceBoundary, commonResponsePattern
>    }
> }
>
> Then add the following:
>
>  ## The location information used to generate the response
>  div {
>    locationUsed = element locationUsed {
>      attribute id { xsd:NCName } | locationInformation
>    }
>  }

Done, except:
   I placed the cardinality in the locationUsed pattern.
   Though Relax NG is powerful and can do the loc info echo, I don't  
think we should complicate things to that degree.  The ID is enough.

> div {
>  findService =
>    element findService {
> +      requestLocation,
> -      element location { locationInformation }+,
>      commonRequestPattern,
>      attribute validateLocation {
>        xsd:boolean >> a:defaultValue [ "false" ]
>      }?,
>      attribute serviceBoundary {
>        ("reference" | "value") >> a:defaultValue [ "reference" ]
>      }?,
>      attribute recursive { xsd:boolean >> a:defaultValue  
> [ "false" ] }?
>    }
>  listServices = element listServices { commonRequestPattern }
>  listServicesByLocation =
>    element listServicesByLocation {
> +      requestLocation,
> -      element location { locationInformation }*,
>      commonRequestPattern,
>      attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?
>    }
>  getServiceBoundary =
>    element getServiceBoundary { serviceBoundaryKey, extensionPoint }
> }
>
> Then add the definition as so:
>
>  ## Location, used by findService and listServicesByLocation
>  div {
>    requestLocation = element location {
>      attribute id { xsd:NCName }?, locationInformation
>    }+
>  }

Done.

> (Note: It seems that you intended to have the cardinality of the  
> location element in "listServicesByLocation" as 1..n, rather than  
> 0..n.  The text in Section 11 states "one or more <location>  
> elements".  I've assumed that here, if not, then add a trailing "?"  
> to the line in "listServicesByLocation".)

Nope, looks like you found a mistake.  Henning owes you a beer.

> I haven't used xsd:ID.  It might be more appropriate to use the ID  
> type defined in "http://relaxng.org/ns/compatibility/datatypes/0.9",  
> but that seems a little under-defined based on what I'm reading  
> right now.

Given that the URL returns 404, I'd say yes to "underdefined".  I  
think your definition is good.

> I also recommend changing the type of the service number to be based  
> on xsd:token to allow for non-meaningful whitespace.  Based on the  
> given pattern, whitespace is illegal (<serviceNumber> 911</ 
> serviceNumber> == bad, for more than one reason).  That is  
> unintuitive, so a small change is appropriate:
>
>      element serviceNumber {
>        xsd:string { pattern = "[0-9*#]+" }
>      }?,
> ->
>      element serviceNumber {
>        xsd:token { pattern = "[0-9*#]+" }
>      }?,

Agreed.  Done.

> The same goes for "message" and maybe "appUniqueString".  xsd:string  
> should be used rarely, unless you particularly like whitespace  
> nightmares (see [1]).

Given that message is essentially free form text, I don't see how it  
makes a difference.  But I see no harm.  Done.

-andy
_______________________________________________
Ecrit mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ecrit