Re: Schema for Extensible Enumerative Attributes

[Stephen Green <stephen.green@documentengineeringservices.com>]

Oh dear, Dennis, I'm finding myself
warming to it. Maybe I was a little unfair
in dismissing it so easily.

        <xs:simpleType name="codeExtension_type">
		<xs:restriction base="xs:QName">
			<xs:pattern value="[\c-[:]]+:[\c-[:]]+"/>
		</xs:restriction>
	</xs:simpleType>
	
The pattern is quite simple and the way to add
custom enumerations would be quite neat and
easy (for the editor, not difficult to specify and for
the implementer not too difficult to undertsand from
the spec).

I'd still like to see if the TC is OK with it but I'm
prepared to back it. It does, after all, meet those
requirements I have put forward in preventing typos
while allowing quite sensible, simple customisation.
Let's just see if the TC as a whole are OK with it
before making another iteration to include it, if so.

Thanks and thanks especially for your patience.

Best regards
---
Stephen D Green




2009/11/15 Stephen Green <stephen.green@documentengineeringservices.com>:
> It does work, but I don't like the idea of using it
> because it seems counter to the use of QName to
> not allow a default namespace, in my opinion.
> Plus I don't really like the idea of using a QName
> like a string with a string-like pattern. I do like the
> idea of ensuring a typo is caught by the schema
> and schema-aware parser but using a pattern like
> this and adding more complexity than QName
> alone seems to be rather costly to implementers.
> I'd prefer to defer to the TC on this one.
>
> Best regards
> ---
> Stephen D Green
>
>
>
>
> 2009/11/15 Stephen Green <stephen.green@documentengineeringservices.com>:
>> Isn't that overengineering things?
>>
>> Remember that any attribute can be added to
>> a prescription element with whatever datatype
>> required as an extension using the anyAttribute.
>> The QName (or for that matter, if the TC agrees
>> to use it, the normalizedString - v1.0.0.2 - or
>> NCName - v1.0.0.1) is good enough for most
>> purposes but if you need more, or a more
>> specific restriction or union, you can specify a
>> custom attribute to use instead of 'level'
>> (or 'conflict' if the element is one of the shared
>> TA parts).
>>
>> I'll try it out of academic curiosity but I really
>> don't think we should restrict things any more
>> (unless the TC as a whole agrees otherwise).
>>
>> Best regards
>> ---
>> Stephen D Green
>>
>>
>>
>>
>> 2009/11/15 Dennis E. Hamilton <dennis.hamilton@acm.org>:
>>> Try this:
>>>
>>> <xs:simpleType name="codeExtension_type">
>>>   <xs:restriction base="xs:QName">
>>>      <xs:pattern> value="[\c-[:]]+:[\c-[:]]+">
>>>          <xs:annotation> Any QName with a ":" in it, a PrefixedName
>>>          </xs:annotation>
>>>      </xs:pattern>
>>>   </xs:restriction>
>>> </xs:simpleType>
>>>
>>>  [ ... ]
>>>
>>> <xs:simpleType name="prerequisiteConflictCode_type">
>>>  <xs:union memberTypes="prerequisiteConflictBaseCode_type
>>> codeExtension_type"/>
>>> </xs:simpleType>
>>>
>>> <xs:simpleType name="prerequisiteConflictBaseCode_type">
>>>  <xs:restriction base="xs:NCName">
>>>    <xs:enumeration value="conjunction"/>
>>>    <xs:enumeration value="disjunction"/>
>>>  </xs:restriction>
>>> </xs:simpleType>
>>>
>>>  [ ... etc. ]
>>>
>>> This should allow all PrefixedName QName forms that are namespace
>>> well-formed and it should reject all Unprefixed NCNames that are not in the
>>> list of enumeration values.
>>>
>>> I imagine the reason that QName is a base data type is for its use in the
>>> XML Schema for XML Schema itself.  Fancy that!
>>>
>>>  - Dennis
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
>>> http://lists.oasis-open.org/archives/tag/200911/msg00068.html
>>> Sent: Sunday, November 15, 2009 10:35
>>> To: stephen.green@documentengineeringservices.com
>>> Cc: 'TAG TC List'
>>> Subject: RE: [tag] Re: Checking Enumerative QNames for the TAML-defined
>>> simple values
>>>
>>> Hmm, I don't think it is a default namespace problem.  I think it is because
>>> we are not requiring a colon in the QName.
>>>
>>> Suggestions:
>>>
>>> Under <xs:simpleType name="prescriontLevelBaseCode_type> I suggest that you
>>> use
>>>  <xs:restriction base="xs:NCName">
>>>
>>> Under <xs:simpleType name="codeExtension_type"> do what is needed to require
>>> a colon in the QName using a pattern.
>>>
>>>
>>>  - Dennis
>>>
>>> -----Original Message-----
>>> From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf
>>> Of Stephen Green
>>> http://lists.oasis-open.org/archives/tag/200911/msg00067.html
>>> Sent: Sunday, November 15, 2009 09:33
>>> To: dennis.hamilton@acm.org
>>> Cc: TAG TC List
>>> Subject: [tag] Re: Checking Enumerative QNames for the TAML-defined simple
>>> values
>>>
>>> Yep, it does work - see latest schema (TAML v1.0.0.3)
>>>
>>> http://www.oasis-open.org/committees/download.php/35196/testAssertionMarkupL
>>> anguage-1-0-0-3.xsd
>>>
>>> [ ... ]
>>>
>>> I note though that the following is also valid (without a prefix):
>>>
>>> <testAssertion xmlns="http://docs.oasis-open.org/tag/taml/200911";
>>>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>> xsi:schemaLocation="http://docs.oasis-open.org/tag/taml/200911
>>> http://www.oasis-open.org/committees/download.php/35196/testAssertionMarkupL
>>> anguage-1-0-0-3.xsd"
>>> id="illustation-1-0" schemaVersionId="1.0.0.3" time="08:39:23.312"
>>> date="2009-11-30">
>>>     <prescription level="deprecated"/>
>>> </testAssertion>
>>>
>>> because of XML Schema rules, so the namespace prefix is optional.
>>>
>>> I'm not expert enough to know for sure why this is but
>>> I guess it might be because the attribute itself does not need
>>> a namespace declaration; something to do with it automatically
>>> taking the default namespace?? Anyway, that it a bit too geeky
>>> for me to worry me. Just suffice that the namespace and prefix
>>> happen to be optional. The side effect of that is that folk have
>>> to be aware that the schema will not catch typos for the built-in
>>> values; i.e.
>>>
>>> [ ... ]
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>
>>>
>>
>