[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?
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]