[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tag] Re: Considerations for TAML Authoring and normalizedString
I think QName is too different from an ordinary string. There are too many legitimate types of string it doesn't allow, e.g. URIs, URLs even. Best regards --- Stephen D Green 2009/11/15 Dennis E. Hamilton <dennis.hamilton@acm.org>: > I think we were cycling too rapidly. > > My clarifying proposal was to use QName, as stated here > > <http://lists.oasis-open.org/archives/tag/200911/msg00043.html>. > > - Dennis > > PS: I feel like I bullied you into a concession. That is not my desire. We > can agree to disagree and see what is important to the other members. We > ran through this pretty quickly. We could use other perspectives, I think. > Maybe we should let the dust settle before going another round on this > topic. > > -----Original Message----- > From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf > Of Stephen Green > http://lists.oasis-open.org/archives/tag/200911/msg00049.html > Sent: Saturday, November 14, 2009 14:19 > To: dennis.hamilton@acm.org > Cc: TAG TC List > Subject: Re: [tag] Re: Considerations for TAML Authoring and > normalizedString > > now I'm confused. I thought you were proposing NCName rather than > normalizedString. > > Best regards > --- > Stephen D Green > > > > > 2009/11/14 Dennis E. Hamilton <dennis.hamilton@acm.org>: > http://lists.oasis-open.org/archives/tag/200911/msg00048.html >> 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 > http://lists.oasis-open.org/archives/tag/200911/msg00047.html >> 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>: > http://lists.oasis-open.org/archives/tag/200911/msg00041.html >>> 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 >> >> > > --------------------------------------------------------------------- > 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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]