6 General guidelines
29.2403GPP3GPP Generic User Profile (GUP)NetworkRelease 17Stage 3TS
The GUP architecture has identified three kinds of entities: (1) client applications, (2) GUP servers and (3) data repositories [point to stage 2]. For the communication between these entities, two interfaces have been defined, namely Rp and Rg.
Communication between GUP entities is performed via the exchange of messages expressed as XML documents. XML documents should include the XML declaration with the version and encoding attributes. The XML documents shall be well-formed and valid. The W3C XML Schema [3,4] is used in GUP to define the structure of valid XML documents.
The implementation of the Rp and Rg interfaces follows the Liberty Alliance Data Service Template specification [Liberty Alliance].
From a Liberty Alliance point of view, GUP servers and data repositories will play the role of Liberty Alliance data services.
6.1 Reusing Liberty Alliance DST
Liberty Alliance Data Service Template [13] specification proposes a framework for web services that offer access to data in general. In the context of GUP, the data services should be restricted to GUP user profile data.
The Data Service Template defines: (1) some abstract definitions about messages that are sent and received by the web service and (2) some guidelines regarding the structure of the data offered through the service.
More concretely, the Liberty Alliance Data Service Template [13] specification offers a set of incomplete XML schemas with placeholders (for data types) that need to be filled based on the nature of the data offered by the data service.
In the context of GUP, we will:
– fill the place holders with some GUP specific data types, and
– add some new messages that are not offered by the Data Service Template specification
The details of this instantiation of the Liberty Alliance Data Service Template for each GUP component are summarized in corresponding check list tables presented in Annex A together with the actual definition of the GUP component.
The guidelines and naming conventions recommended by Liberty alliance when using XML and XML Schemas are directly applicable to GUP.
6.2 Guidelines for XML usage
As described in Liberty ID-WSF Data Services Template Specification [13], the schemas of the different data services, and GUP in particular, should follow a set of guidelines that are included in this specification with the purpose of completeness.
6.3 GUP Specific Naming and Namespaces
The namespace URI for GUP specific XML documents is a 3GPP specific namespace identifier ‘http://3gpp’ followed by a namespace specific string starting with ‘gup’ followed by ‘ns’ and a sub-namespace specific for a certain namespace. (The ‘ns’ is used to grouping instances of the namespace type of URIs together. Other types of usage of URIs may be defined later.) The sub-namespaces are defined in GUP specifications and/or implementations.
Thus the syntax of the URI for all GUP specific namespaces is: ‘http://3gpp/gup/ns/<sub-namespace>’.
The sub-namespace for the GUP Component specific Profile Components consists of the common ‘comp’ part followed by the component name.
The following namespaces are defined for GUP:
– GUP Profile: ‘http://3gpp/gup/ns/profile’
– Common Attributes: ‘http://3gpp/gup/ns/common/<name>’
– GUP procedures: ‘http://3gpp/gup/ns/proc/<name>’
– GUP Components: ‘http://3gpp/gup/ns/comp/<component name>’.
For example an HSS related component URN could be ‘http://3gpp/gup/ns/comp/IMSSubscription’.
Editor’s note: This clause should go into 23.003 when the specification is getting to a stable condition.
6.4 GUP Profile schema
If the Liberty Alliance data service template specifies the interfaces that can be used to access this data, it does not specify the exact nature of the data. In the context of GUP, we need to explicitly define what the subscriber profile data consists of.
3GPP GUP defines a global schema for the XML content of the user profile.
This schema is unique and the same for every user. The schema is defined using W3C XML schemas.
The GUP user profile consists of profile components.
There are many manners to generate the schema for Generic User Profile. But irrespectively of the manner (e.g. one single XML schema vs many schema nested within each other), the schema can always be transformed into a single "canonical" XML schema. A user profile will be a valid instance of this "canonical" schema.
way to define the global schema
will be to define a set of sub-schemas, each with its own namespace. The schema defines a set a single rooted XML documents, each of them being a valid instance of one component defined by the schema. This fact enables easier
schema management as applications should not have to worry about the whole schema, but only the parts they are interested in; when one schema component gets modified, only applications using this component should care about the change. Guidelines for the construction of the profile schema
When designing the schema we want to achieve:
– Modularity
– Extensibility
– Readability
– Easy support for versioning
– Isolation (only applications concerned by the schema component should be affected)
The recommended way to design the GUP schema is to split the schema into schema components, each component being defined as a separate XML schema document, with its own namespace.
Components are assembled together as optional content (minOccurs=0, maxOccurs=1) of an <all> construct.
Common attributes as defined in Liberty ID-WSF Data Services Template Specification [13] shall be used for GUP.
6.4.1 Example
To illustrate this, it is shown how the the top-level component of the GUP schema could be defined as the "concatenation" of four different sub-schemas.
The component is defined by an XML schema document. The component namespace is defined by the targetNamespace of the schema.
The sub-schemas used in the definition are referenced by (1) their namespace declaration in the <xsd:schema> element and (2) by importing their corresponding schema documents (<xsd:import>).
Finally, the top-level component is defined by a content-model that concatenates the four sub-schemas under an <xsd:all> contruct. We now illustrate how we can build components out of other components. Let it be assumed that there are four components (c1 … c4), represented by four distinct namespaces (nsc1 … nsc4) , described in four different schema files; they can be put together as follows:
|
<?xml version="1.0"?> <xsd:import namespace="http://3gpp/gup/profile/c1" <xsd:element name="Top"> |
Note the benefits that we achieve using this way of doing things:
– Modularity: the GUP schema does not consist of a monolithic standalone document, but rather a collection of small schemas that can be designed and maintained independently.
– Extensibility: at every level, it is possible to extend the schema by simply adding one child to the <xsd:all>.
– Readability
– Support for versioning
6.5 Data Referencing Language
For referencing components, the GUP Component Language (GCL) shall be used.
The GCL is a subset of the XPath 1.0 language [XPath reference], as defined below.
Editor’s note: we only use the name "GCL" as a way to avoid confusion. In the final version of this document, the name will be skipped or replaced.
Editor’s note: we need to define the LA name to identify the GCL for the discovery service. Probably something like: xpath-gup-gcl.
6.5.1 Language Syntax for GCL
The following subset of XPath shall be supported by GCL:
– only the child:: and attribute:: axis of XPath are supported
– predicates are supported
– expressions inside predicates only apply to attribute nodes or element nodes with no children
– expressions inside predicates shall be of the form "node <op> value" where <op> ranges over the usual string and arithmetic operators.
– boolean negation is supported
– ordinal predicates are supported (e.g. [1], [last()], [position()<=2])
NOTE: AND and OR are not part of the syntax because they can be emulated by already existing language constructs: A[exp1 AND exp2] corresponds to A[exp1][exp2]; A[exp1 OR exp2] corresponds to A[exp1] | A[exp2].
6.5.2 Semantics
The semantics of the GCL language can be defined as follows:
1. we evaluate the GCL expression on the document using the XPath semantics leading to a set of nodes
2. for each node in the set, we also include its descendants and its ancestors
This defines a new document, sub-document of the original document.
6.6 GUP metadata
The 3GPP Rp and Rg interfaces define the management of data and metadata for user profile components. For the sake of uniformity, Rp and Rg do not define special procedures for metadata management. Rather, we distinguish between user profile components (or data components) and metadata components.
We define two kinds of metadata components: access control metadata and mapping metadata. The definition of other metadata components (e.g. billing, etc.) is beyond the scope of this specification.
In the following definition, ResourceIDGroup and SelectType are defined by Liberty Alliance.