[dsdl-discuss] Re: Namespace renaming

Many thanks for your helpful comments Ken.

You disagreed with:
> >b) assigning all elements with a specific prefix to a different prefix,
> >without changing the URI
stating that
> 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.

But the question is whether or not DSRL can be used to transform a document,
or just to convert its internals for validation purposes. I know the primary
purpose of DSRL is the second of these options, but must it preclude the
first? For example, should it be possible to just apply DSRL and then output
the DOM with these changes in place?

You asked:

> Aren't these [cases c and d] 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).

They probably are, but the problem is that there in no link between the URI
and a prefix in DSRL. What happens if I want to assign a new prefix to the
existing name to avoid a name clash? Do I go xmlns:old-prefix="xyz"
xmlns:new-prefix="xyz" and then transform old-prefix:x to new-prefix:x. What
happens to attributes with no namespace qualifier if I do this (do they get
assigned to the new-prefix or remain assigned to the old-prefix)?

You stated:

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

My problem is that I don't know which prefixes are in scope. Do I have to
declare all source and result element prefixes, or just the result element
prefixes, in the map? In fact, the map only needs the DSRL prefix, the
others are superfluous as far as the definition of the map is concerned as
they only affect the source and result instances! Umm...

The problem resolves to:

> I think any result DSRL produces will have to be well-formed XML
> which will require the namespaces to be properly declared and
> used.

What constitutes a proper declaration of namespaces in maps that are to
convert one instance to another instance?

Martin

----- Original Message -----
From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
To: <dsdl-discuss@dsdl.org>
Sent: Monday, December 05, 2005 1:07 AM
Subject: [Norton AntiSpam] [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)
>
>

--
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)