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

[Eliot Kimber <ekimber@rsicms.com>]

I think I see your point: for generalization processing you would have to at
least know what the namespace name of the ancestor type was so you could
produce a correctly-namespaced instance of the element.

That's probably sufficient to scuttle this line of thought.

Cheers,

E.


On 5/18/12 1:37 PM, "Nitchie, Chris" <cnitchie@ptc.com> wrote:

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