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] 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).


Eliot Kimber, Owner
Contrext, LLC

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.




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