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

[Eliot Kimber <ekimber@rsicms.com>]

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-binding";
>>  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/