OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [wsrp] Types for names

During today's Interfaces SC call, I was tasked to check if it valid to 
have QNames without namespace URIs.

Per the XML Schema Spec (http://www.w3.org/TR/xmlschema-2), the value 
space of QName is the set of tuples {namespace name, local part}, where 
namespace name is an anyURI and local part is an NCName.

This makes me think that namespace name is required. In the Java-land 
(e.g. javax.xml.namespace.QName), it is valid for QNames to have empty 
strings as namespace URIs, but namespace URIs cannot be null.

Given this, it may be awkward to make implementations use empty 
namespace URIs when the use case actually requires NCNames. The best 
examples are mimeHeaders and formParameters.



Rich Thompson wrote:
> It came up on the Interfaces SC yesterday that we ought to tighten up 
> the fields where names are defined as a number are currently typed as 
> xsd:string and xsd:QName is often more appropriate for avoiding name 
> clashes. A scan of the spec suggests the following fields be changed:
> ItemDescription.itemName? -> text currently _suggests_ this be a URI ... 
> would a QName be better?
> PropertyDescription.name
> Property.name
> ResetProperty.name
> NamedString.name? -> gets used for mimeHeaders and form parameters, but 
> a QName is allowed to have a missing prefix
> I am not including the ResourceList related name fields as those are 
> highly localized and therefore should not suffer from name clash issues 
> (at least none that the Producer can not completely manage).
> Rich

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]