A key scope name has the same rules as a key name.
Periods are allowed in key scope and key names to allow maximum flexibility to map designers reusing topics with keyrefs initially authored in a scoped environment. We want to make it as easy as possible for map authors to reuse topics containing (possibly)
(sometimes) scoped key references.
For example, if a topic contained
<xref keyref="products.productA.introduction"/>
That topic might be reused in
A large publication containing product and marketing information - e.g. containing keyscope="products", keyscope="productA" and keys="introduction" A product-specific map with multiple products, e.g. one containing keyscope="products.productA" and keys="introduction" A flat map specific to Product A, containing keys="products.productA.introduction"
Chris
From: <
dita@lists.oasis-open.org > on behalf of Jim Tivy <
jimt@bluestream.com >
Date: Tuesday, March 22, 2016 at 1:10 PM
To: 'Eliot Kimber' <
ekimber@contrext.com >, "
dita@lists.oasis-open.org " <
dita@lists.oasis-open.org >
Subject: RE: [dita] key names
Yes, agreed.
On URIs the only thing DITA can do is make them IRIs in the future – if the escaping is upwardly compatible.
How about disallowing “.” in keyscope names? Where is the definition of what makes a keyscope name?
From: Eliot Kimber [ mailto:
ekimber@contrext.com ]
Sent: March-22-16 10:07 AM
To: Jim Tivy;
dita@lists.oasis-open.org Subject: Re: [dita] key names
@Href values are URIs and therefore must conform to URI rules, including escaping. There's nothing DITA can or should do on that account.
"." must be allowed in key names because it was allowed before 1.3 and there are use cases for overriding scope-qualified names in a higher-level scope by declaring a name that matches the scope-qualified
version (this is why it must always be allowed to define keys that are the same as the scope-qualified version).
Cheers,
E.
----
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com From: dita <
dita@lists.oasis-open.org > on behalf of Jim Tivy <
jimt@bluestream.com >
Date: Tuesday, March 22, 2016 at 11:54 AM
To: dita <
dita@lists.oasis-open.org >
Subject: [dita] key names
Couple of points came up in todays call – so thought to weigh in.
In most Unicode and XML encoding aware XML editing environments characters from the Unicode character set can be inserted as attribute or element values.
Editing environments do this because in general unescaped characters strings are more useful to humans than escaped character strings
In this context, a simple approach would be to put no restrictions on the characters used in any attributes whether they be called href or key names or keyref.
However, restrictions on key names can be useful and on hrefs critical. For example, for an href to support the notion of identifiers that can use relative addresses “../mydir1/mydir2/myfile.xml” it is critical
to refer to a specification like the URI spec or in the future perhaps the IRI spec. This is means a “sub-syntax” is at play within the DITA XML document. When we say the String form is according to the URI spec it means escaping is necessary in the XML
context. However in a DITA aware XML editor you could decide to let people put in unescaped values and save it to XML under the covers as escaped – that is a UX matter – not a spec matter.
For key names, however, we should go with what we consider a good naming discipline – which NMToken is.
This avoids punctuation and other characters in names making names more usable.
As well, allowing dots in keynames and keyscope names is bad practice because we have defined “.” as a keyscope qualifier character. Whether bad practice becomes illegal is a point of discussion. There can be
no simple rule for parsing – unlike file extension which is the last set of characters after the last dot. So you are putting a burden on implementors.
{Does anyone know in the spec where it specifies the characters allowed in the KeyScope name?}
It seems some “sub-syntax” is necessary for hrefs and likely key names. Enforcement of this sub-syntax is transferred to the processor and we should make it as easy as we can for the processor if it does not cost
in usability.
cheers
Jim