[dsdl-discuss] Re: Namespace renaming

Again Ken, many thanks for your comprehensive response.

You mentioned in a couple of places that you couldn't see the scenario for
needing to switch namespace prefixes. Let me give you one, which is a
practical problem that I am working on at present.

For our documentation and help file production we want to be able to deliver
XHTML and PDF from files that are marked up in a tightly controlled subset
of HTML, SVG and MathML. We don't want to have a lot of namespaced elements
entered into the source files, which have to be created by relatively
unskilled people, so we are doing things like renaming div to section,
renaming a to link, and even html to document. We are restricting the
allowed set of MathML to the set of elements that we can easily transform
into XSL-FO and PDF, and at the same time only using that subset that is
relevant for our applications, rather than the full blown complex MathML
set. The schema for the restricted set of tags has its own namespace, e.g.
xia. However, what I need to do is to transform my xia:section elements as
html:div before online delivery, and I want to use the XHTML transformation
as a basis for creating WordML versions of files for external editing. I can
do all this with XSLT, but it would be nice if I could generate this XSLT
automatically from a simple mapping definition such as DSRL instead of
expecting my doc specialist customers to be fully conversant with XSLT.
Hence my lack of concern when WG1 suggested that we should allow prefix
renaming as part of the functionality of DSRL.

My real problem is that we have a scenario that has:

Source Schema --> DSRL Map --> Target Schema

I know the namespace of the two end points in this list, and that the DSRL
Map is in the DSRL namespace, but what information does the DSRL map need to
hold re the prefixes and associated URIs of the end-points, and should this
information be held in a form that is "DOM viewable" or in the form of
attributes whose values could be slotted into XSLT statements at appropriate
points?

Martin

Martin

----- Original Message -----
From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
To: <dsdl-discuss@dsdl.org>
Sent: Tuesday, December 06, 2005 1:13 AM
Subject: [Norton AntiSpam] [dsdl-discuss] Re: Namespace renaming

> At 2005-12-05 18:43 +0000, Martin Bryan wrote:
> >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?
>
> Oh, I totally agree that DSRL should be used to transform a document,
> but I do not believe that changing namespace prefixes is a way that
> should be allowed.
>
> Since prefixes in the instance are not used for validation (consider
> that RELAX-NG use of prefixes is solely in the constraint expression;
> as far as I understand one cannot constrain the prefixes used an XML
> in any fashion; all validation is done with the URI-qualified names
> having already processed the prefixes), then the ability to rename
> the prefixes should have a null effect on the validation task. Of
> the top I cannot think where a user of DSRL is going to get a net
> benefit in validation by having the ability to change prefixes.
>
> As for transforming a document and translating prefixes on the way in
> to prefixes on the way out, that is fraught with insoluble
> incompleteness ... while simple things can be done simply, there are
> holes in how XML is used that would prevent a total solution from
> ever working. If a total solution can never work, why implement a
> partial solution?
>
> Consider XSLT and the use of prefixed namespace-qualified names in
> XPath attributes ... changing the prefixes in the instance and in the
> namespace declarations would render the resulting well-formed XML
> instance as being invalid to XSLT because the embedded XPath
> addresses use prefixes that may not be bound (or worse, improperly
> bound) to namespace URI strings.
>
> And even if you could somehow state "we know about XSLT so make sure
> XPath addresses are suitably translated" (which I think cannot be
> done because how would one rewrite a totally arbitrary XPath address
> sitting in an attribute), DSRL would know nothing of my UBL
> vocabulary in which I have arbitrary XPath addresses in attributes
> and I bind the URI strings through namespace declarations in scope.
>
> In my experience, prefixes should be treated with kid gloves because
> messing with them can easily overlook the author's intent.
>
> >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.
>
> But we can mandate such a link, couldn't we? Couldn't we state that
> whenever a prefix is used in an attribute specifying qualified names
> that there must be a namespace in scope binding the URI string?
>
> And, like XPath 1, couldn't we mandate that in DSRL the absence of a
> namespace prefix is necessarily indicating "no namespace" and not the
> default namespace? I admit I haven't thought this through, but this
> is surely my intuition.
>
> >What happens if I want to assign a new prefix to the
> >existing name to avoid a name clash?
>
> Not sure how with document-wide context of DSRL (I'm assuming that)
> one would be able to do that ... wouldn't the name clash already be
> present in the input? I guess I don't understand the scenario you
> are positing.
>
> >Do I go xmlns:old-prefix="xyz"
> >xmlns:new-prefix="xyz" and then transform old-prefix:x to new-prefix:x.
>
> Well, I think my claim is that we not allow that ... qualified names
> in attributes get shortchanged.
>
> >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)?
>
> That's easy: XML states that attributes without prefixes are in no
> namespace, they aren't in the default namespace and they aren't in
> the namespace of the element. They are just in no namespace.
>
> Consider <x:y xmlns:x="urn:x-x" a="a" x:a="xa"/> ... if an
> unprefixed attribute were in x's namespace we'd have a collision ...
> which we don't have ... so they must be separate attributes ...
> therefore an unprefixed attribute is never in the element's namespace
> and never in the default namespace.
>
> >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.
>
> Why not? In XSLT one can examine the namespace axis. In other
> languages you can probably either walk the tree (in a DOM-like
> situation), or track namespace declarations (in a SAX-like situation)
> and successfully keep track of things.
>
> >Do I have to
> >declare all source and result element prefixes, or just the result
element
> >prefixes, in the map?
>
> I don't think you have to "declare" them explicitly (I think this is
> a failing of Schematron since it requires namespaces to be explicitly
> declared) I think an implementation can simply examine the namespaces
> in scope to ensure things are as they should.
>
> >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...
>
> True ... I'm only worried about having features in DSRL where we
> inadvertently give our users enough rope to hang themselves. Where
> something that solves a simple problem simply is too simple to
> accommodate real-world situations where DSRL breaks results.
>
> >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?
>
> I think there should always be exactly one way to declare namespaces,
> that being the XML way of declaring namespaces in scope of
> elements. For the processing of any DSRL element, any referenced
> prefixes in qualified names would implicitly be related to the
> namespaces in scope in the XML instance.
>
> 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)