[dsdl-discuss] Re: Namespace renaming

At 2005-12-04 19:41 +0000, Martin Bryan wrote:
>During the Atlanta meeting one of the tasks assigned to me as editor of DSRL
>was to add namespace renaming to Part 8. (In fact the scope of Part 8
>already includes the statement "including the assignment of element and
>attribute names to different namespaces".)
>
>I had originally thought that this would be a simple task, but now I am not
>so sure. There are a number of problems, each of which raises specific
>issues. The tasks required include, but are not limited to:
>
>a) assigning all elements in a source namespace (e.g. HTML) to an
>alternative namespace (e.g. XHTML) which has a different URI

Absolutely ... and remember that in XSLT the namespace URI string is
not used for such a situation in <namespace-alias
stylesheet-prefix="x" result-prefix="y"/> is stating "literal result
element nodes in the stylesheet using prefix "x" are to be built in
the result tree using the URI string associated with prefix "y" (and,
implicitly, using the prefix "x" in the result tree).

>b) assigning all elements with a specific prefix to a different prefix,
>without changing the URI

I disagree ... I think (b) is out of scope. Prefixes are cosmetic
and irrelevant in an XML instance in general, though not cosmetic and
irrelevant in XSLT stylesheets because of the semantics of XSLT
creating instances in which prefixes are used.

I would have guessed that the prefix was not part of the XML
information set, but I would have then been wrong. It is, but it is
surely regarded as second class:

 From section 2.2:

   [prefix] The namespace prefix part of the element-type name. If
the name is unprefixed, this property has no value. Note that
namespace-aware applications should use the namespace name rather
than the prefix to identify elements.

There are also a few other references, but my point is that all along
applications are supposed to be written to be prefix agnostic.

And ... what to do about the default namespace when there is no
prefix ... be sure to accommodate its specification.

Finally, by not having such a facility, we keep to standards like
XSLT the vagaries of "qualified names in attributes" that I hinted at
above. In my discussion (a) prefixes are tools in the stylesheet to
reference the URI strings. Such prefixes must be preserved in the
result tree because when one uses XSLT to create XSLT, the created
XSLT will have qualified names in attributes (XPath addresses). A
stylesheet writer needs predictability when writing a result tree
that the attributes with qualified names in the result tree point
with prefixes appropriately declared in the result tree.

So ... say we implement (b) ... how would we be able to run this
process on an XML instance in which attribute values have qualified
names, such as attribute values with XPath addresses? In my
volunteer work I have a number of instances of UBL namespaces with
attributes that contain namespace-qualified names because these
attributes are used in the synthesis of Schematron assertions and
XSLT stylesheets. I don't think it would be very clean to cover all
of the bases in implementing (b) while accommodating XML instances in
which attributes have namespace qualified names.

>c) assigning specific elements to a different namespace with a the same (or
>a newly defined) URI to avoid name clashes
>d) assigning specific attributes to a different namespace so that their
>original ones can be used for new purposes (I actually came across this use
>case last Friday, where I wanted to replace a user-assigned ID with a
>system-assigned one, with the user-assigned ID being preserved as a
>different attribute in a specific namespace).

Aren't these accommodated simply by the renaming of elements and
attributes (thereby satisfying what used to be HyTime architectural
forms? I think there is a role for this in UBL and I'm hoping to use
DSRL for some experiments).

>Case a) would seem to require something along the lines:
><dsrl:change-namespace-prefix source="html" source-URI="...." target="xhtml"
>target-URI="..."/>

I think the URI attributes should be removed and that the URI's be
derived from the prefixes and the namespaces in scope.

>The only question is to whether this is valid as it does not declare either
>of the namespaces themselves. Should we be using:
><dsrl:change-namespace-prefix source="html" xmlns:html="...." target="xhtml"
>xmlns:xhtml="..."/>
>instead?

Oh ... yes, actually ... that was what I was trying to say. Sorry
for not reading ahead in enough detail.

>A problem with the latter approach is that I am not sure it can be used with
>case b), where it would be necessary for two prefixes to be supplied to the
>same URI. Is there any reason why XML would forbid this?

I don't believe it is forbidden.

>Is is deemed acceptable practice?

I don't find it distasteful.

>Do we need to specify the namespaces as being namespaces?

I think we needn't bother and that we only access namespaces by
looking at namespaces in context, as already defined by XML.

>We already have a mechanism for case c) in the dsrl:element-name-map option,
>where we can have one of three representations, such as
><dsrl:element-name-map>xyz:new-element-name</dsrl:element-name-map>. My only
>question in this case is whether there needs to be some control on the
>namespaces used, and what form this control should take. Should we require
>that all namespaces referenced in a map be declared within it so that we can
>ensure that correct URI occurs in the transformed file? If so should the
>references be allowed to have local scope, or should they be global?

I think these questions are moot if we adopt existing mechanisms.

>Or
>should we assume that the DTD/Schema used to validate the result will
>declare the namespace URI that matches the prefix used in the map (can it do
>so?)

I think any result DSRL produces will have to be well-formed XML
which will require the namespaces to be properly declared and
used. Again, though, such well-formedness has no awareness of
namespace usage in attribute and element values.

>The problem of scoping is even more critical for attribute redefinition. At
>what point should the URI be declared for the prefix? Should the renaming
>redefine it on every mapped element, only on the root element, or will some
>form of inheritance checking need to be used to check whether the prefix/URI
>pair is already in force at this point? (This last option seems to me to be
>difficult to require as we are supposed to be doing things declaratively,
>and I was hoping to be able to do transformations using XLST 2.0).

I think they can already be done in XSLT 1.0 with the namespace::
axis ... things are even easier in XSLT 2.

I hope this helps.

. . . . . . . . . . Ken

--
Upcoming XSLT/XSL-FO hands-on courses:  Denver,CO March 13-17,2006
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/d/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/d/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)