RE: [dita] DITA and Namespaces? A Potential Compromise Solution for DITA 1.3?

["Nitchie, Chris" <cnitchie@ptc.com>]

I'm fine with something like this in 2.0 (in fact, I think DITA 2.0 must
account for namespaces), I'm just squeamish about it in 1.3.

Let me give a concrete example of where I think this could cause some
headaches. We have a way of determining which elements are understood by
a given stylesheet. When we publish a DITA document, we run the document
through a complex preprocessing step which, among many other things,
converts elements not styled by the stylesheet to elements which are,
via analysis of the @class attribute.

So say we have this tag in a document:

<someTag class="+ topic/ph nsDomain/foo:nsph myDomain/myph " .../>

Let's say <myph> is not handled by the stylesheet, but the tag 'nsph' in
the namespace mapped to the prefix 'foo' is. We're going to have to
resolve/expand the class attribute in order to match foo:nsph to against
the list of styled elements. Then, we're going to have to determine if
that namespace URI is currently established at this location in the
document; if not, we're going to have to add an xmlns:(somePrefix)
attribute to establish it, and then replace <someTag> with
<(somePrefix):nsph>. Whereas currently, we make the assumption that
there are no namespaces, and so it's trivial to match @class tokens
against the list of tags styled by the stylesheet, and similarly trivial
to rename the element.

Chris

-----Original Message-----
From: Eliot Kimber [mailto:ekimber@rsicms.com] 
Sent: Friday, May 18, 2012 12:10 PM
To: Nitchie, Chris; dita
Subject: Re: [dita] DITA and Namespaces? A Potential Compromise Solution
for DITA 1.3?

Note that I'm not arguing that hard for us to consider this change for
1.3.

But I do want to highlight the important aspect of my proposal, namely
that
if we allow prefix-qualified values in @class (meaning we relax the rule
that the tagname must always exactly match a value in @class), then it
is
possible to do normal @class processing of namespaced specialized
elements
as long as you are willing to assume that the prefix in the @class value
is
mapped to the namespace name it should be, which is a pretty safe
assumption
in most cases, because the values will be set within DTDs or XSDs.
There's
no need to resolve the prefix in this case, you're just treating it as
part
of the element type name string, just as you would "lc" or "d4p_" in
existing vocabularies that use this style of name prefix to get most of
the
effect of namespaces.

There is no change to the way @class can be used to bind processing to
elements: it's still a simple string match. The only change is that the
tag
name of the element with the @class value might have a different prefix
or
no prefix. But in practice nobody cares because nobody normally
validates
that rule, at least not that I'm aware of.

If you *do* want to do 100% namespace-aware @class processing, for
example,
to verify that your assumptions about the prefix are correct, then you
would
have to dereference the prefixes in the @class value. That would be
extra
processing, but that processing wouldn't be *required* just to do normal
DITA-aware processing. It would be an optional level of validation that
you
could do or not.

The advantage is that it would allow DITA to use namespaces for
specializations. The disadvantage would be we'd have to define a
separate
DITA-specific prefix binding mechanism to support the case where
processors
do want to do the full validation or use namespace names rather than
prefixes for class matching.

Or we could say, for DITA 1.3, you can use namespace prefixes but
processors
are not expected to dereference the prefixes and if you want a formal
binding for the prefix you do it with normal namespace declarations.
That
enables the use of namespaces without adding any new markup, simply be
relaxing current name-matching rules. A more complete namespace binding
mechanism could be added in DITA 2.0, when we're likely to completely
rethink the whole class mechanism in any case.

But it sounds like nobody is particularly excited about this idea enough
to
consider it for 1.3, which is pretty much what I expected.

Cheers,

Eliot

On 5/18/12 9:32 AM, "Nitchie, Chris" <cnitchie@ptc.com> wrote:

> You're right about unqualified attributes always being in the null
namespace;
> I'd thought that was different when the default namespace of the
document was
> non-null, but I was wrong.
>
> My big concern is that this takes something that's currently trivial -
@class
> attribute analysis - and makes it non-trivial, or at least
considerably less
> trivial. The @class attribute being so foundational to how DITA works,
that
> makes me uncomfortable.
>
> Chris
>
> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@rsicms.com]
> Sent: Thursday, May 17, 2012 5:48 PM
> To: Nitchie, Chris; dita
> Subject: Re: [dita] DITA and Namespaces? A Potential Compromise
Solution for
> DITA 1.3?
>
> Not sure I understand your statement about getting @class attributes
from
> namespaced elements. Unqualified attributes are always in no
namespace.
>
> That is, for
>
> <foo:element class="some value" xmlns:foo="ns1">
>
> The namespace of the attribute @class is no namespace.
>
> There is additional processor work required to dereference namespaced
terms
> in a @class value--that's why we've so far rejected the possibility.
>
> So my query is really "are my simplifying assumptions sufficient to
make it
> viable in some 1.x version or is it still too hard in the general
case?".
>
> The only processing environment I can think of where the necessary
> processing power isn't at least potentially available is direct CSS
styling
> of DITA XML, but I'm not sure that's actually being done as a matter
of
> common practice.
>
> Otherwise, any DITA-aware processor will be implemented in some
language
> that could do the dereferencing with a little implementation effort,
e.g.,
> XSLT, Java, XQuery, Adept Command Language, direct DOM processing. It
would
> definitely add some overhead to element processing.
>
> One thing I've done in the DITA for Publishers code is implemented an
XSLT
> function library that provides a "class()" function that hides the
details
> of determining if an element is of a specific class. I did this partly
> because it's good XSLT 2 engineering practice and partly because it
would
> provide for a future where the rules for class determination are more
> involved.
>
> Cheers,
>
> Eliot
>
> On 5/17/12 4:25 PM, "Nitchie, Chris" <cnitchie@ptc.com> wrote:
>
>> I think there are a couple of things about this that strike me as
being too
>> hard for implementors to support to be included in 1.*. It's going to
be
>> tricky to get the @class attribute from a namespaced element because
the
>> namespace of the @class attribute itself will vary. For example,
existing,
>> DITA-compliant processors that use xpaths would have to change
instances of
>> "@class" to "@*[local-name()='class']". Similar changes would need to
be made
>> for DOM or SAX-based processing. One potential workaround would be to
require
>> tags in the non-default namespace use ditaarch:class or something,
but that
>> still requires extra work for processors to support (and doesn't
solve
>> similar
>> problems for other standard DITA attributes on namespaced elements).
And
>> assuming we figured out a backwards-compatible way to get a tag's
class,
>> correctly expanding qnames in the class will require varying degrees
of extra
>> work from processors. While expansion may not be required in all
cases, it
>> will be required in some fairly common ones:
>>
>> - Determining if tag 'a' is derived from tag 'b', if 'b' is in a
namespace
>> - Fallback generalization to a namespaced element
>>
>> Even given some of the simplifying assumptions you describe, class
attribute
>> analysis goes from being simple analysis of the string as-is to
requiring
>> some
>> degree of resolution before processing.
>>
>> I do think namespaces are something DITA needs to support, I'm just
skeptical
>> that it can be done in 1.x without requiring major upgrades of
existing
>> tools.
>>
>> Chris
>>
>> From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On
Behalf
>> Of Eliot Kimber
>> Sent: Thursday, May 17, 2012 4:43 PM
>> To: dita
>> Subject: [dita] DITA and Namespaces? A Potential Compromise Solution
for DITA
>> 1.3?
>>
>> In response to a recent DITA Users posting that happened to have
documents
>> that showed specialized elements in a namespace, I was writing that
having
>> namespace prefixes caused the problem that namespace prefixes needed
to be
>> dereferenced in order to do element-to-type matching. But then I
realized
>> that's only true if you want to have your matching defined in terms
of
>> namespace names, rather than prefixes. But if you're willing to match
on
>> prefixes then everything works except for a single validation edge
case,
>> namely determining the that the element type matches a term in the
class
>> value
>> when the element's prefix isn't the same as that used in the @class
value.
>>
>> DITA currently has the rule that the tagname must match one of the
terms in
>> the @class value. This makes it possible to validate that the element
is in
>> fact of a type named in the @class value. For example, given the
element:
>>
>> <foo>
>>
>> DITA requires that the class value include " module/foo " where
"module"
>> could
>> be any module name.
>>
>> One reason we've said we can't use namespace is because the tagname
could
>> have
>> a prefix different from that used in @class value (see example
below).
>>
>> However, that requirement is really only necessary for validation
that the
>> element matches its class hierarchy. If we ignored that requirement,
then
>> namespaced names in @class would be just as good as unnamespaced
names--they
>> would be equally invariant and equally easy to match on using simple
string
>> matching.
>>
>> That leaves the problem of validating that a given element is in fact
the
>> element type named in its class value. For example, consider these
two
>> elements:
>>
>> <bar:foo xmlns:bar="http://example.com/ns1";
>>   class="- topic/topic bar:foo/bar:foo "
>>>
>>
>> <foo xmlns="http://example.com/ns1";
>>   class="- topic/topic bar:foo/bar:foo "
>>>
>>
>> Both elements are of the same type--{http://example.com/ns1}:foo--but
the
>> first one satisfies the DITA "tagname matches class" rule and the
second does
>> not.
>>
>> To enable complete validation of the type to the class, we would need
a
>> separate DITA-specific namespace declaration, e.g.:
>>
>> <foo xmlns="http://example.com/ns1";
>>
xmlns:dita_ns="http://oasis-open.org/DITA/namespace/DITA-ns-prefix-bindi
ng"
>>  dita_ns:bar="http://example.com/ns1";
>>  class="- topic/topic bar:foo/bar:foo "
>>>
>>
>> Where the @dita_ns:bar attribute is binding the prefix "bar" as used
in the
>> @class attribute.
>>
>> You can't simply also declare the prefix "bar" on the <foo> element
because
>> the prefix may already be bound to a different namespace, e.g.:
>>
>> <foo xmlns="http://example.com/ns1";
>>   xmlns:bar="http://example.org/ns2";
>>   dita_ns:bar="http://example.com/ns1";
>>   class="- topic/topic bar:foo/bar:foo "
>>>
>>
>> Emphasizing that in the general case you cannot predict or control
what
>> namespace bindings will be used in a given XML instance.
>>
>> This suggests to me that for DITA 1.3 we might be able to relax the
namespace
>> use rules a bit if we did the following:
>>
>> 1. Allowed the use of namespaced specializations under the following
>> conditions:
>>
>> A. The tagname is an exact match to a term in the @class value, e.g.
>> "bar:foo"
>> in the example above. This is the case where the prefix used in the
@class
>> value is also declared on the element and is, presumably, the
namespace
>> intended by specializer. That is, in this case we assume that the
document
>> matches the specialization intent without bothering to validate it.
This will
>> cover 90% of the cases where in fact namespace prefixes are preserved
and the
>> document is correct.
>>
>> B. The local name matches the local name of the last term in the
@class
>> value,
>> e.g. "foo" in the example above. This doesn't catch the case where
the
>> element
>> is in fact not in the same namespace as that bound to the prefix in
@class,
>> but we could say that for DITA 1.x that's user error and don't do
that. This
>> would catch 9 of the remaining 10% of cases, that is, where an editor
or
>> other
>> processor moves the namespace binding from a prefix to being the
default
>> namespace (the second form of the bar:foo element shown above).
Again,
>> there's
>> no validation that the element really is in the same namespace as
bound to
>> the
>> prefix used in the @class value, we're just assuming it's correct
because
>> usually it will be.
>>
>> C. Add a DITA-specific prefix-binding attribute like the dita_ns:*
attribute
>> shown above for those cases where there is a requirement to
completely
>> validate elements to @class prefix bindings. It would be optional in
that its
>> use would be optional and conforming processors would not be required
to
>> implement it. But it would be easy enough to implement in XSLT 2 or
>> Schematron, so I wouldn't be concerned about having at least one
available
>> implementation.
>>
>> This would all be in advance of a more complete namespace solution in
DITA
>> 2.0, where presumably matching is done entirely in terms of namespace
names,
>> not prefixes.
>>
>> I'm pushing on this only because it seems a little weak to have to
say that
>> DITA can't use namespaces for what seems, upon analysis, to be a
pretty minor
>> technicality that, in practice, has little value in day-to-day
practice.
>>
>> Does this analysis make any sense?
>>
>> Cheers,
>>
>> E.
>> --
>> Eliot Kimber
>> Senior Solutions Architect, RSI Content Solutions
>> "Bringing Strategy, Content, and Technology Together"
>> Main: 512.554.9368
>> www.rsicms.com
>> www.rsuitecms.com
>> Book: DITA For Practitioners, from XML Press,
>> http://xmlpress.net/publications/dita/practitioners-1/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: dita-help@lists.oasis-open.org
>>
>
> --
> Eliot Kimber
> Senior Solutions Architect, RSI Content Solutions
> "Bringing Strategy, Content, and Technology Together"
> Main: 512.554.9368
> www.rsicms.com
> www.rsuitecms.com
> Book: DITA For Practitioners, from XML Press,
> http://xmlpress.net/publications/dita/practitioners-1/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: dita-help@lists.oasis-open.org
>

--
Eliot Kimber
Senior Solutions Architect, RSI Content Solutions
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.rsicms.com
www.rsuitecms.com
Book: DITA For Practitioners, from XML Press,
http://xmlpress.net/publications/dita/practitioners-1/