of points came up in todays call – so thought to
most Unicode and XML encoding aware XML editing
environments characters from the Unicode
character set can be inserted as attribute or
environments do this because in general
unescaped characters strings are more useful to
humans than escaped character strings
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.
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.
key names, however, we should go with what we
consider a good naming discipline – which
avoids punctuation and other characters in names
making names more usable.
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.
anyone know in the spec where it specifies the
characters allowed in the KeyScope name?}
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.