RE: [tag] Re: Considerations for TAML Authoring and normalizedString

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

I don't think NCNames should be allowed for extensions.  NCNames are basic
XML Names (such as element names and attribute names and ID values) having
no colons.  That is, an NCName is an XML Name with no colon.  In a QName, an
NCName by itself is the unqualified case.  The fixed names that we have so
far are (coincidentally) proper restrictions on NCNames.  Allowing custom
extension using the same syntax (NCName) is the problem I thought we were
trying to avoid.

The introduction of RDF/RDFa into a test-assertion is entirely separate from
this.

What we are doing with NCName as the base is not providing an extension
mechanism.  That's certainly a way to end this debate.  I'm just not sure it
is what you intended.

 - Dennis

 

-----Original Message-----
From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf
Of Stephen Green
Sent: Saturday, November 14, 2009 13:20
To: dennis.hamilton@acm.org
Cc: TAG TC List
Subject: [tag] Re: Considerations for TAML Authoring and normalizedString

OK, Dennis, I'm conceding and making the base datatype
for custom extensions to the enumerated types NCName,
as now in draft 1.0.0.1
http://www.oasis-open.org/committees/download.php/35189/testAssertionMarkupL
anguage-1-0-0-1.xsd

I concede that the square bracket and 'ext:' prefix mechanisms
put too much restriction on implementers who might wish to
also implement something akin to RDFa/XHTML in their test
assertions.

It still concerns me that there are few values which would not
be valid codes and there needs to be care to ensure that typos,
etc are somehow picked up where they might not be detected
by the 1.0.0.1 schema. I guess it is an acceptable risk though.

Best regards
---
Stephen D Green




2009/11/14 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.
> [ ... ]
>
>

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php