OASIS Darwin Information Typing Architecture (DITA) TC

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

Title: DITA and Namespaces? A Potential Compromise Solution for DITA 1.3? Hi Eliot   Interesting discussion domain. I am not sure which problem you are solving. All elements have a namespace URI or no namespace.  The prefixes are purely there for ease of use and have no value in of themselves.  A good XML parser will expand the names appropriately so you can obtain the full namespace URI for any node.   I am not sure which of the following areas you are addressing – or did I miss the area:   1. Schema Validation (Syntax check) A Dita XML processor wants to validate the structure of the XML with respect to Dita Schemas or DTDs. I am unsure how different namespaced elements play into this outside of foreign. The type of an element can be known using the PSVI (Post Schema Validated Instance) of the  XML.   2. Presentation Inheritance using the class attribute A “Dita Publisher Process” (such as the OT) wants to base presentation on an element’s class or super class when converting to a given output type presentation.  To allow polymorphism and to avoid changing the “Dita Publisher Process”, presentations can be inherited by sub classed elements.   3. Semantic Analysis Is the class correct for the given element and other tests not done by a Schema Validation.     From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf Of Eliot Kimber Sent: May-17-12 1: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/

I'm concerned with item (2) in your list--matching elements to processing based only the value of the @class attribute. The issue with prefixes has to do with what goes in the @class value. If you use prefixes, then you have to have a way to resolve those prefixes to namespace names. If you use namespace names directly, then the class values get very long. If the @class value uses prefixes then either those prefixes have to reflect the local prefix bindings for the elements they appear on or there has to be a separate, DITA-specific prefix-to-namespace binding for each prefix. The first option is really not practical since it would mean having to modify an otherwise invariant attribute in processing contexts where the prefixing of the elements might change, such as in XML editors or in DITA-to-DITA transforms. I can't imagine anyone signing up for that. The second option, a DITA-specific prefix binding, is easier to implement but then requires processing in DITA-aware processors. But it would be doable and the values involved could be invariant for a given document instance or DTD set (because the only requirement would be that the binding match the @class values, it would have no direct relationship to the prefixes used on the element tags or attributes). So really this is a question of whether this is worth entertaining at all in 1.x. I suspect the answer is "no" but I wanted to at least get my thoughts on the record. Cheers, E. On 5/17/12 4:08 PM, "Jim Tivy" <jimt@bluestream.com> wrote: > Hi Eliot > > Interesting discussion domain. > I am not sure which problem you are solving. > All elements have a namespace URI or no namespace. The prefixes are purely > there for ease of use and have no value in of themselves. A good XML parser > will expand the names appropriately so you can obtain the full namespace URI > for any node. > > I am not sure which of the following areas you are addressing ­ or did I miss > the area: > > 1. Schema Validation (Syntax check) > A Dita XML processor wants to validate the structure of the XML with respect > to Dita Schemas or DTDs. > I am unsure how different namespaced elements play into this outside of > foreign. > The type of an element can be known using the PSVI (Post Schema Validated > Instance) of the XML. > > 2. Presentation Inheritance using the class attribute > A ³Dita Publisher Process² (such as the OT) wants to base presentation on an > element¹s class or super class when converting to a given output type > presentation. To allow polymorphism and to avoid changing the ³Dita Publisher > Process², presentations can be inherited by sub classed elements. > > 3. Semantic Analysis > Is the class correct for the given element and other tests not done by a > Schema Validation. > > > > From: dita@lists.oasis-open.org [ mailto:dita@lists.oasis-open.org ] On Behalf > Of Eliot Kimber > Sent: May-17-12 1: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 > < http://example.com/ns1%7d: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/

Hi Eliot The class attribute hack in DITA - is a beautiful thing because it works simply and has got us to where we are. The "right" way to do it would be to demand a PSVI tree (See XQuery/XPath Spec and discussion of Post Schema Validated Instance) (like the schema aware Saxon). In which case you could ask the element node for its schema type and its inheritance tree and thus no need for the class hack. I think we should start thinking about DITA as an in memory PSVI kind of thing then answers to these questions will just drop out. This goes along the lines that XML is an InfoSet or PSVI and the text we see is just a serialization. Ideally your non DITA namespaced content would know its type in PSVI. Since we use the class attribute, then you must set a type of the element in the class attribute or use the xml:type attribute for the namespaced content. As you may have been getting at... With regards to embedding prefixes it is done other places with an understanding that they can be expanded. For example <billTo xsi:type="ipo:Address"> Or... <Class abbreviatedIRI="myOnt:Animal"/> To expand them requires having the prefix definitions remembered - which might be manual in some environments. Prefix resolution might be possible with something like: string(/*/namespace::my) in XSLT - does anyone know the right way? Another way is to declare a universal prefix within the DITA realm - which is a bit fragile. Jim >
Original Message----- > From: Eliot Kimber [ mailto:ekimber@rsicms.com ] > Sent: May-17-12 2:58 PM > To: Jim Tivy; dita > Subject: Re: [dita] DITA and Namespaces? A Potential Compromise Solution > for DITA 1.3? > > I'm concerned with item (2) in your list--matching elements to processing > based only the value of the @class attribute. > > The issue with prefixes has to do with what goes in the @class value. > > If you use prefixes, then you have to have a way to resolve those prefixes to > namespace names. > > If you use namespace names directly, then the class values get very long. > > If the @class value uses prefixes then either those prefixes have to reflect > the local prefix bindings for the elements they appear on or there has to be > a separate, DITA-specific prefix-to-namespace binding for each prefix. > > The first option is really not practical since it would mean having to modify > an otherwise invariant attribute in processing contexts where the prefixing > of the elements might change, such as in XML editors or in DITA-to-DITA > transforms. I can't imagine anyone signing up for that. > > The second option, a DITA-specific prefix binding, is easier to implement but > then requires processing in DITA-aware processors. But it would be doable > and the values involved could be invariant for a given document instance or > DTD set (because the only requirement would be that the binding match the > @class values, it would have no direct relationship to the prefixes used on > the element tags or attributes). > > So really this is a question of whether this is worth entertaining at all in 1.x. > > I suspect the answer is "no" but I wanted to at least get my thoughts on the > record. > > Cheers, > > E. > > On 5/17/12 4:08 PM, "Jim Tivy" <jimt@bluestream.com> wrote: > > > Hi Eliot > > > > Interesting discussion domain. > > I am not sure which problem you are solving. > > All elements have a namespace URI or no namespace. The prefixes are > > purely there for ease of use and have no value in of themselves. A > > good XML parser will expand the names appropriately so you can obtain > > the full namespace URI for any node. > > > > I am not sure which of the following areas you are addressing ­ or did > > I miss the area: > > > > 1. Schema Validation (Syntax check) > > A Dita XML processor wants to validate the structure of the XML with > > respect to Dita Schemas or DTDs. > > I am unsure how different namespaced elements play into this outside > > of foreign. > > The type of an element can be known using the PSVI (Post Schema > > Validated > > Instance) of the XML. > > > > 2. Presentation Inheritance using the class attribute A ³Dita > > Publisher Process² (such as the OT) wants to base presentation on an > > element¹s class or super class when converting to a given output type > > presentation. To allow polymorphism and to avoid changing the ³Dita > > Publisher Process², presentations can be inherited by sub classed > elements. > > > > 3. Semantic Analysis > > Is the class correct for the given element and other tests not done by > > a Schema Validation. > > > > > > > > From: dita@lists.oasis-open.org [ mailto:dita@lists.oasis-open.org ] On > > Behalf Of Eliot Kimber > > Sent: May-17-12 1: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 > > < http://example.com/ns1%7d: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/

On 17.5.2012 22:42, Eliot Kimber wrote: > 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 " Wouldn't it be easier to use Clark notation in @class and prevent all problems related to prefixes and QNames used in attributes, something like: <bar:foo xmlns:bar=" http://example.com/ns1" ; class="- topic/topic { http://example.com/ns1}foo/{http://example.com/ns1}foo " @class would be verbose then but this shouldn't matter as it is automatically injected from schema into document. I think that given current performance penalty of relying on @class values for matching using indirection mechanism here (prefixes) would decrease perfomance by another grade. Jirka -- ------------------------------------------------------------------ Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz ------------------------------------------------------------------ Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing ------------------------------------------------------------------ OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member ------------------------------------------------------------------ Attachment: signature.asc Description: OpenPGP digital signature

Yes, Clark notation would work, but it would be very verbose. It would have a meaningful effect on storage of DITA content in CMS systems that store documents fully expanded (e.g., MarkLogic). Not that that's sufficient to disqualify the approach, but it is a concern. It would also make the code that matches on those values verbose or necessarily indirect but not through normal namespace prefix means (that is, you'd have to create XSLT variables for the namespace names so you could then refer to them in match expressions). I guess I'd rather have a more compact syntax at the cost of a little processing. Moore's law continues to hold but verbose syntax is always verbose. Cheers, E. On 5/22/12 1:43 PM, "Jirka Kosek" <jirka@kosek.cz> wrote: > On 17.5.2012 22:42, Eliot Kimber wrote: > >> 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 " > > Wouldn't it be easier to use Clark notation in @class and prevent all > problems related to prefixes and QNames used in attributes, something like: > > <bar:foo xmlns:bar=" http://example.com/ns1" ; > class="- topic/topic > { http://example.com/ns1}foo/{http://example.com/ns1}foo " > > @class would be verbose then but this shouldn't matter as it is > automatically injected from schema into document. > > I think that given current performance penalty of relying on @class > values for matching using indirection mechanism here (prefixes) would > decrease perfomance by another grade. > > Jirka > -- 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/

On 22.5.2012 21:56, Eliot Kimber wrote: > I guess I'd rather have a more compact syntax at the cost of a little > processing. Moore's law continues to hold but verbose syntax is always > verbose. Maybe I missed something, but this "little processing" would mean that for each @class attribute you would need to: 1. Find all "DITA namespace declarations" (dita_ns:* attributes) which are in scope 2. Based on this replace prefixes in @class attribute by corresponding namespace URI 3. Do a match on replaced @class with namespace URI + original element name after : This is actually quite complex thing to do. In XSLT 2.0 you can create user defined function to do this and use it for template matching. But I can't imagine how to do this in XSLT 1.0. Jirka -- ------------------------------------------------------------------ Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz ------------------------------------------------------------------ Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing ------------------------------------------------------------------ OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member ------------------------------------------------------------------ Attachment: signature.asc Description: OpenPGP digital signature

For XSLT 1 you'd simply have to do the look directly in your match expression--you wouldn't be able to hide it behind a function. So it could be done in XSLT 1, but it wouldn't be pretty. In any case, it's a moot point for DITA 1.3 since we decided we're not going to pursue this at this time. Cheers, E. On 5/22/12 3:26 PM, "Jirka Kosek" <jirka@kosek.cz> wrote: > On 22.5.2012 21:56, Eliot Kimber wrote: > >> I guess I'd rather have a more compact syntax at the cost of a little >> processing. Moore's law continues to hold but verbose syntax is always >> verbose. > > Maybe I missed something, but this "little processing" would mean that > for each @class attribute you would need to: > > 1. Find all "DITA namespace declarations" (dita_ns:* attributes) which > are in scope > > 2. Based on this replace prefixes in @class attribute by corresponding > namespace URI > > 3. Do a match on replaced @class with namespace URI + original element > name after : > > This is actually quite complex thing to do. In XSLT 2.0 you can create > user defined function to do this and use it for template matching. But I > can't imagine how to do this in XSLT 1.0. > > Jirka -- 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/