wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Types for names
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Thu, 2 Jun 2005 15:16:21 -0400
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 <subbu@bea.com>
06/02/05 12:26 PM
|
To
| wsrp <wsrp@lists.oasis-open.org>
|
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]