Re: [wsrp] Types for names

There is an ability to have the namespace
part missing, but then a collection of rules about default namespaces apply.
I am not sure if they would trip up this use of QName since the quick look
I did concerned elements and attributes while we would be using the QName
type as the value of either an element or attribute. Anyone interested
in making a detailed investigation of the default namespace rules?

Rich 

Subbu Allamaraju <>

06/02/05 12:26 PM

To

wsrp <>

cc

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.

Regards,

Subbu

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

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  You may a link to this group and all your TCs
in OASIS

at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php