Comment re: designation of xlink:label as NCName

A project within SC4 of ISO is working on the specification of an XML
representation of product data as defined in entity-based information
models defined in EXPRESS, the information modeling language specified as
ISO10303-11. This work has included  the use of Xlink to represent the
links between XML elements  that correspond to product data entities. Since
the objective is to represent product data that is defined by information
models, we need to define a mapping from associations in the information
model to links in the product data. (Using the terminology from UML --  in
which a link is an instance of association --which is a family of
structurally and semantically related links that can be defined within an
object model.)

The problem that I have encountered is with the July 2000 version of Xlink
wherein the xlink:role attribute for arc-type elements has become
xlink:label. In the process its data type changed from QName to NCName. We
had been able to model and to prototype inter-enterprise product data based
on the former version but I believe it is no longer possible with the new
approach. The problem is that entities and their associations are defined
in EXPRESS SCHEMAs for us and we have been planning to map schema names to
namespace URIs in order to disambiguate elements that belong to different
schemas. Accordingly, we could define a "hasPart1" association in two
different schems. The two associations would represent different
relationships and would be distinguished by Namespace qualified names. It
is a requirement for us to be able to represent a link that can instantiate
both "hasPart1" associations. In the information model the association is
designated by its from/to xlink:labels and its xlink:arcrole. Without QName
xlink:labels it is no longer possible to do this. The following example
illustrates:

<osb:uos  xmlns:p = "urn:iso10303-28:oseb.piping_schema"
      xmlns:q = "urn:iso10303-28:oseb.some_other_schema"
          xmlns:osb = "urn:iso10303:oseb">

<p:Joint_Key
    xlink:type = "extended" >

   <osb:this
        xlink:type = "resource"
        xlink:label = "osb:this"
   </osb:this>

  <osb:lockey
         xlink:type = "locator"
         xlink:href = ?#xpointer(Part_Key[@Id= "P7"  and
               namespace() = "urn:iso10303-28:oseb/piping_schema"])?
          xlink:label = "p:hasPart1"   />

<osb:lockey
         xlink:type = "locator"
         xlink:href = ?#xpointer(Part_Key[@Id= "T2"  and
               namespace() = "urn:iso10303-28:oseb/piping_schema"])?
          xlink:label = "q:hasPart1"   />

   <osb:go
          xlink:type = "arc"
          xlink:from = "osb:this"
          xlink:to = "p:hasPart1"
          xlink:arcrole = "p:hasPart1"  />

<osb:go
          xlink:type = "arc"
          xlink:from = "osb:this"
          xlink:to = "q:hasPart1"
          xlink:arcrole = "q:hasPart2"  />


</p:Joint_Key>

</osb:uos>

As you can see, there is no way now to fully specify an association in an
information model:

The first association hasPart1 that is contained in ../piping_schema refers
to "p:hasPart1" as its xlink:to.

It is now possible for a second schema to be defined, ../some_other_schema
and within that schema a hasPart2 association can be defined to refer to
"hasPart1" as its xlink:to. Without a qualifed xlink:label, we can no
longer model such an association. If this association is defined to use
"hasPart1" as its xlink:to, there is no way to disambiguate this label from
the other "hasPart1" in the link element.

I was hoping that it might make sense to you to return to the former plan
of designating the xlink:label as QName instead of NCName.

Regards,
Tom Rando

Received on Sunday, 3 September 2000 12:44:39 UTC