[dsdl-discuss] Re: [Schematron-love-in] DSDL Part 5 (DTLL)

Rick hi
 
>
> Daniel Cazzulino wrote:
>
> > I agree. 1 is better, and is easier to implement on non-XSLT
> > implementations, I think. It looks more natural and along
> the lines of
> > what we're already used to with EXSLT extensions...

+1
 
> Should we use the same mechanism for datatypes defined using
> DTTL schemas and for the XSD built-in dataypes?
>
> So
> dttl:validate( @date, jp:japanese_date )
> dttl:validate( @date, xs:date )
> where
> * an XSLT2 implementation might implement both using DTTL
> transformation and

I'd thought that DTLL will specify an 'XSD emulation' set of datatype
definitions (as an annex to the standard), but that these would have a
Namespace _like_ .../dsdl.org/dtll/xsd-emulation/, and not use the
official XSD type Namespace.

> * a C#/Java/C++ implementation might implement the first
> using a regex library and the second
> by calling the appropriate datatype-checker in its
> native XSD API
>
> DTTL probably does not sustain all the semantics of XSD
> datatypes.

I'd be very interested to know where it can't/doesn't.

> It would cause some confusion sometime if the
> Xpath2 implementation caught fewer errors than the non-XSLT2
> implementions. But should that really be a killer?

... In fact, I'm not sure it would be acceptable if we couldn't totally
mimic XSD types, warts and all.

> Schema people traditionally place a high value on certainty:
> all conforming implementations should produce the same
> objective answer when validating. Of course, it all falls
> apart a little when dealing with regex classes and Unicode
> and XML1.0 v XML 1.1 and anything that evolves. But users
> live with it.
>
> I don't see the harm (except to expectations) of saying that
> where a DTTL library models the type constraints of an public
> external typesystem, an implementation is free to validate
> using some internal library rather than the DTTL schema.

I agree, but I do see harm (for 'marketing' reasons if nothing else) of
implying that the DTLL implementation might be less capable.
  
> This is really an exception applying to XSD datatypes only at
> the moment. From the user's POV, they are invoking DTTL type
> library. From the implementer's POV they are not using the
> DTTL type library (and, indeed, they may decide only to
> support the XSD types first.)
>
> That seems to give the most freedom to implementers.
>
> From the ISO DSDL part 5 ISO DTTL POV, I guess what we might
> be looking at is
> * The addition in part 10.3 of a new function, such as
> dt:validate( node(s), type) returning boolean
> Someone could have a better function name for this.
> * A 1-page normative annex, with 1 or 2 paragraphs, called
> "Using ISO DTTL with ISO Schematron"
> Saying "Use it as a function in assertion test only.
> Define namespace prefix in ns: elements. Assertion fails with
> error if function is not available from implementation. " and
> then example with XSD library and non XSD library.

I was thinking the annex would be in Part 3 :-)

There needs to be descriptions somewhere of how Part 5 fits with Parts
2, 9 and maybe 10, too.
 
> Cheers
> Rick
> --
> DSDL members discussion list
>
> To unsubscribe, please send a message with the command
> "unsubscribe" to dsdl-discuss-request@dsdl.org
> (mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)
>
>
>

--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)