OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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/



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]