[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tag] Proposal: Providing Decentralized Extensiblity of Enumerative-Attribute Values
Thinking about this some more, I think there are a great many reasons to use a restricted syntax for enumerated-value identifiers. Secondly, I think it is valuable to use a syntax that is already defined and also has appropriate semantics. My preference is to use the QualifiedName syntax already nicely defined in the [xml-names] specification. In addition, I would add the proviso that when a PrefixedName is present, it be a valid CURI (eliminating the need for brackets altogether). This makes life very easy. You should not need to borrow any special syntax in the schema, although QualifiedName does have a BNF definition. Being wide-open with normalized attribute values raises all sorts of problems with regard to internationalization, preservation in UIs, etc. (NCName has issues too, but it is a well-delimited case.) Being wide-open also raises more complicated cases of deciding when a special case is present rather than being merely a coincidental use of the general case. I think your use of brackets was intended to forestall that, although I haven't checked it carefully. I'm inclined to be more restrictive and much simpler. - Dennis PS: There is an architectural principle that is vaguely applicable here. "It is always easier to relax a restriction in the future than there is to impose a restriction that did not apply previously." That has a lot of weight with me. -----Original Message----- From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green Sent: Friday, November 13, 2009 09:46 To: dennis.hamilton@acm.org Cc: TAG TC List Subject: Re: [tag] Proposal: Providing Decentralized Extensiblity of Enumerative-Attribute Values CORRECTION sorry, by <quote> but so would this level="deprecated" </quote I meant <quote> but so would this level="[deprecated]" </quote> Best regards --- Stephen D Green 2009/11/13 Stephen Green <stephen.green@documentengineeringservices.com>: > Re: 3.1 (1) / 3.2 (1) > > I'm not sure, though I'd need to investigate this some > more, that restricting the base datatype of enumerations > beyond normalizedString has a lot of benefit. If the > datatype is normalizedString then I would have thought > it can still be used for URIs and QNames. > > I propose this as a simple type for custom enumerations > > <xs:simpleType name="codeExtension_type"> > <xs:restriction base="xs:normalizedString"> > <xs:pattern value="\[\S.*\]"/> > </xs:restriction> > </xs:simpleType> > > xs:normalizedString would permit both URIs and QNames. > The pattern \[\S.*\] would require that a code be surrounded > by square brackets which should then be easily removed > to provide a normalized string such as a URI and I hope > this would be not just consistent with RDFa but with pretty > much any other enumeration scheme such as a simple > codelist. The surrounding square brackets just ensure the > strinng is not one of the built-in TAML codes misspelt, etc. > > This would be allowed, for example: > > level="[http://docs.oasis-open.org/tag/taml/20100920/deprecated]"; > > but so would this > > level="deprecated" > > and for RDFa implementations, etc the "anyAttribute" allows this > > > level="[deprecated]" > resource="http://docs.oasis-open.org/tag/taml/20100920/extendedcodelist.xsd"; > > or presumably whatever other syntax the RDFa requires. > > I propose to put this pattern in the next draft schema (if nobody > objects - we could still change it later of course). > > Thanks for good input Dennis. I hope I haven't missed your point. > > > Best regards > --- > Stephen D Green > > > > > 2009/11/10 Dennis E. Hamilton <dennis.hamilton@acm.org>: >> I had mentioned this some time ago, and then failed to fulfill the action item about it. >> >> 1. ENVIRONMENT >> >> 1.1 This applies to Test Assertion Markup Language as a particular framework under the model. >> >> 1.2 This might also be tied to provisions for unambiguous extension of terms for certain enumerations in the TA Model as well. >> >> 2. OBJECTIVE >> >> 2.1 A number of fixed terms are specified for certain attribute-value choices in the TA Markup Language. >> >> 2.2 It is desirable to allow use of custom values for those attributes as well, but in a way where the custom values are unambiguous and can be chosen without concern for confusion with the values fixed in the schema or with values introduced by others. >> >> 3. PROPOSAL >> >> 3.1 Where there are specific fixed-choices for an attribute where custom choices are permitted, >> >> (1) restrict the attribute schema to values of type anyURI >> >> (2) specify that the syntax of the fixed choices will always conform to NCName syntax. >> >> (3) require that custom values for the attribute will always be absolute URIs. >> >> (4) where convenient, one might also allow a CURIE syntax using PrefixedName syntax as a shorthand for the absolute URIs. >> >> (5) the fixed values should also have matching absolute URIs using a namespace that is defined by and for the TA Markup Language. >> >> 3.2 Simplified alternative (Recommended for its harmony for use of TAG terms in RDF): >> >> (1) restrict the attribute schema to values having the syntax of QualifiedName (XML Namespace syntax) >> >> (2) specify that the syntax of the fixed choices will always conform to NCName syntax. >> >> (3) required that custom values for the attribute will always be with Compact URIs (CURIEs). >> >> (4) Define a namespace by which the fixed names can be used in CURIEs as well as without namespace prefixes (corresponding to (5) above). >> >> 4. PRECEDENT >> >> These kinds of arrangements are being used to allow for customization in some XML office-document markup formats and as a way of adding extensibility to certain attribute-value choices in formats such as HTML and XHTML. >> >> [RDFa-XHTML] RDFa in XHTML: Syntax and Processing -- A collection of attributes and processing rules for extending XHTML to support RDF. W3C Recommendation 14 October 2008. Available at <http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/>. See section 2.1 for the general idea and sections 3.8 and 5.4 for CURIE and URI processing. (The peculiar structure of RDF in examples doesn't matter, this is just about how attribute values are treated as namespaced terms.) >> >> >> >> - Dennis >> >> Dennis E. Hamilton >> ------------------ >> NuovoDoc: Design for Document System Interoperability >> mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 >> http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org >> >> >> --------------------------------------------------------------------- >> 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]