[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Schema limitations, normative dependencies, and related topics
Stephen, there are a number of observations in your remarks about architectural principles and ways to deal with various situations that I wanted to remark on, but not as part of the specific discussion of the use of QNames or other extension mechanisms for enumerative values. My remarks are at least semi-off-topic and I am keeping them in this separate response. 1. With regard to restricting first, rather than relaxing first: I realize that, when there are many serious stakeholders, there is a tendency to destrictify in order to maintain some level of consensus. I don't think we are in that situation where there are disparate implementations and interests to be accommodated. If so, I suspect such stakeholders would speak up during a public review. I do think that the experience leading up to HTML 5 extension mechanisms, and the way that RDFa is introduced as an extension model reflects specific experience that is applicable for us. 2. It seems to me that a schema validator can never determine when a code value is a mistake, it can only determine when a code does not have the specified syntax and/or specific value. In the case of a QName, the processor can clearly distinguish between unprefixed (and specific-valued) and prefixed values (whether extensions or well-known ones). 3. The way that OASIS deals with coupling among their standards is that normative dependence of one standard on another requires that a specific version of the other standard be cited, and that all OASIS standards be depended on normatively in this way. 3.1 Revisions of the depended-upon standard have no effect until it is chosen to update the dependency in a revision of the referencing standard. As far as I can tell, ISO is also very specific about this. Otherwise, conformance is not grounded, and that tends to be unacceptable. So for the TAML specification, I assume you will refer to specific versions of XML, [xml-names], [xml-schema], [xml-id] if used, etc. 3.2 There are also relatively clean OASIS guidelines about our declaring when a namespace can be updated versus when a new namespace is required, with or without grand-fathering local names from its predecessor. 4. Uh, with regard to relying on other standards, isn't that what standards are for? Being relied upon to avoid constant deviating re-approximation of a known, thought-out solution? I feel like we are going down a build-versus-buy NIH rat-hole. I'm sure that's not what is meant. We are using XML after all. "Standards are arbitrary solutions to recurring problems." - Robert W. Bemer. -----Original Message----- From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green http://lists.oasis-open.org/archives/tag/200911/msg00029.html Sent: Friday, November 13, 2009 12:40 To: dennis.hamilton@acm.org Cc: TAG TC List Subject: Re: [tag] Proposal: Providing Decentralized Extensiblity of Enumerative-Attribute Values [ ... ] I'm, also, not entirely convinced about adoption by one standard of any other particular standard unnecessarily; that would be akin to breaking the design principles of loose coupling. If the one standard changes or become obsolete the other standard is jeapordised. Plus there may be another standard become prevalent within the lifetime of the markup which is thereby precluded. As long as we don't preclude the said standards I think we should keep away from actually adopting any standard unless it is a core requirement to the markup and I don't think that is so here. Even with RDFa and W3C there seems to be an effort with XHTML/RDFa to avoid any change to XHTML beyond a profile. The profile itself even falls short, apparently, of tight coupling with CURI - it allows CURI but does not, I think, require it. That would be as far as I would want to go but I would not want to make CURI a normative reference. It barely seems core enough to test assertions. If there were a place for that it might be in an RDF representation of the model, if there. The needs to provide a mechanism for extending code values, though we hardly have a strong need to do so, can, I think be met without resorting to normative references. The more normative references we have the less easy it is to adopt/implement the markup. Best regards --- Stephen D Green 2009/11/13 Dennis E. Hamilton <dennis.hamilton@acm.org>: > 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 > > --------------------------------------------------------------------- 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]