Considerations for TAML Authoring and normalizedString

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

I think we are in clear disagreement on what it means for
backward-compatibility to start with a super general base type and then make
restrictions within it.  For me, normalizedString as a base type for coded
enumeration-value attributes is inconceivable.

I am prepared to agree to disagree on this one.

 -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

Nevertheless, some related observations:

I'm not sure what you are referring to when you say "it has some major
downsides" but I assume you mean "it" as anything but normalizedString.

I don't think normalizedString provides much.  I have difficulty thinking
this is tighter or more valuable than NCName or QName.  It is also ambiguous
on whether white-space is collapsed or not, unless you also specify that
facet.  (It is also inconceivable to me that having whitespace in these
codes is desirable at all.)

I see no reason to use normalizedString as the base type of attributes meant
to carry coded-value enumerations, extensible or not. (I assume you mean
normalizedString, and XML Schema derived type, when you say "normative
string" below.)

Are we really constrained to an XML Editor use-case where intellisense is
offered or not?  The editors I use support that.  If I was intentionally
using some extensions, I would use a modified schema as a template for
editing.  

Likewise, if I wanted to constrain my use of conformant items, I would make
a constrained version of the schema as a template for editing.  For
authoring, I might even do something so bizarre as to use a DTD as a
template (and I am quite prone to doing that).  I don't imagine I would ever
edit any TAs that I hadn't authored or that weren't authored with a known,
customized template.

I think the users and providers of editors should be allowed to come up with
solutions.  I don't see why we should provide the artifacts other than a
schema that is as specific to the specification as e we can make it.  

 - Dennis

-----Original Message-----
From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf
Of Stephen Green
http://lists.oasis-open.org/archives/tag/200911/msg00030.html
Sent: Friday, November 13, 2009 12:55
To: dennis.hamilton@acm.org
Cc: TAG TC List
Subject: Re: [tag] Proposal: Providing Decentralized Extensiblity of
Enumerative-Attribute Values

Of course, though for markup such as ours it has
some major downsides, especially that authors
using XML editors do not get intellisense offering
them the codes as they write (leaving open the
door to harmful typos) - and I guess our markup is
one which will sometimes be typed by hand like this,
despite this we could opt for the Codelist Represe-
ntation TC methodology of providing all of our codes
in separate artefacts (such as using 'genericode').
I'd rather not resort to this if we can help it for the
reasons described above. Even if we did we would
have still to consider the best datatype to use for
the base type. I find normative string is best in that
it allows all possible codes we and others are likely
to need. The mechanism for extensibility does not
require more than this, if we define the code values
externally, because we do not need to use an XSD
union. We simply treat the enumerated datatype
the same as any other and normativeString is, IMO,
optimal where you merely wish to prevent multiline
content.

Best regards
---
Stephen D Green




2009/11/13 Stephen Green <stephen.green@documentengineeringservices.com>:
> There are many principles relevant here. Having spent many
> years closely monitoring the UBL TC and Codelist Representation
> TC deliberations on this and discussing the same within UBL TC
> I have found that the kinds of conclusions in papers such as this
> one
> http://www.ibm.com/developerworks/xml/library/x-extenum/index.html
> have much merit. The problem is one of how to apply the architecture
> to which we have already subscribed by electing to use XML Schema.
> The schema has to be able to discern certain things, especially it
> really MUST be able to validate the existing, built-in codes. Do we
> really expect to be extending these codes? Even if we do, we need to
> ensure the schema knows the difference between a custom code and
> a mistake. QName alone would allow virtually any string to be valid.
> I'm not sure that price is one worth paying. Plus QName would perhaps
> restrict the custom code values: That might not such be issue unless
> such codes are outside of the control of the customizer, as with an
> externally defined codelist whose code values might not all be valid as
> QNames.
[ ... ]