[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 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]