Re: [tag] Proposal: Providing Decentralized Extensiblity of Enumerative-Attribute Values

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