Time goes by so slowly

[venta]

I'm writing My First XML Schema... it's for a very simple family of XML documents which someone else has defined by saying "yes, well, it's all fairly self-explanatory".

(He's right, it is, though documenting that is actually quite hard.)

However, there is an elephantelement whose value is an ASN.1 GeneralizedTime. How do I express in the schema that that should be the case ?

I can do:

<element name="partyTime" type="xsd:dateTime" minOccurs="0"/>

... but that's not the same thing. How do I refer to ASN.1 entities from inside an XML schema ? ASN.1 does provide a method to encode GeneralizedTime objects into xsd:dateTime format, but I can't see how that's useful.

Or do I just call a GeneralizedTime a string and have done with it?

Comments

[leathellin.livejournal.com]

Well there are a couple of things you can do -

1) Use a very loose validation of ASN.1 GeneralizedTime in the schema such as string and validation/document the format of the XML element is correct else where. This plan tends to be less favoured by me but if the documents you are writing schemas for aren't that complicated otherwise and there is plenty of format validation else where it might be the easiest solution.

2) Create a pattern facet covering some of the formatting rules so that at least glaringly bad data is caught by schema validation and do detailed date and time validation/documentation else where. The downside is of course that validation of the format is split between schema and code.

3) Make it a dateTime as you have said above and transform the format into the correct one for the XML allowing the schema validation to validate all the data type rules but requiring transformation of the data format. Not actually that much effort if you're already transforming back and forth to create the XML in the first place.

You do not appear to be the first person to attempt to map ASN.1 to XML Schema so depending on what you are doing this previous attempt may help you avoid making decisions yourself http://xml.coverpages.org/ASN1toXMLSchemaWhitePaper.pdf :-)

[onebyone.livejournal.com]

transform the format into the correct one for the XML

There's a possible problem there, in that tools to do so (indeed, tools to validate against the schema at all) may not always be present when people are creating documents for test purposes. It's one thing to say they need XML-processing tools in order to validate the document they've created (a step they might skip during development), and another to say they need XML-processing tools in order to create it in the first place.

Of course, converting the date isn't difficult by hand, so the test-mode alternative to processing the document could be "create it in the target format in the first place". Or venta could potentially ship them the tools along with the other stuff she's already sending them.

Finally, there's the question of whether venta needs to provide a schema for the target format (which may be impossible), or a schema for a format which can be converted to the target format (which sounds like a good suggestion to me, but isn't the same thing).

[leathellin.livejournal.com]

It is from my point of view rather hard to continue this without knowing why venta is creating an XML Schema. It is possible to add a fourth to my list of options - don't bother creating a schema but that depends on what is the intended use of this XML. Is there a requirement to validate it only at the test stage? Is the intention that the producing applications validate the XML or is that just an option being suggested? Does the consuming application want to validate it using the XML schema (if the producers aren't going to validate it, there is going to need to be some checking)?

Unless the documents are very simple i'd expect some XML tool use by those creating the documents and even if they decide not to use any XML specific tools or libraries converting a data format isn't that tricky and certainly doesn't suddenly involve a whole shed more overhead.

[venta.livejournal.com]

There isn't really any specific requirement at all to validate it, to be honest.

We might require our users to provide some Stuff(TM) in an XML file, in a particular format. I was struggling with how to document this format, since the two extremes seem to be "look at this example, it's all quite obvious" and "here's a schema". Actually writing intermediate documentation just ends up very wordy, and ends up being "It should have this element, which should contain some of these elements, and might have some of these..."

I figured that the best way to document it would be to provide a loose, wordy description and an example, and to say and here, if you're really picky go and look at the schema. Sadly in order for that to be possible I have to write the schema :)

There's not going to be any transforming of XML data back and forth (at least, there's not expected to be). People are just going to be expected to write a fairly simple XML file to provide some basic data. The consuming application(s) are at present hypothetical. We hope they will exist at some point. I've no idea (since I don't think we'll be writing them) whether they'll be doing any validation, or whether they'll just read in the file and try to make the best of it if there's duff data.

[leathellin.livejournal.com]

If it is basically a specification schema then i'd leave it as a basic string field and document the schema with lots of nice xs:documentation elements. If you think that users might want the schema to provide some basic validation to give them an idea how they're doing then add the pattern to narrow things down a bit.

If the consuming application ever gets defined or data validity is causing problems then a tighter schema can always be issued.

Note: this only works if the documentation of the schema is nice and clear about the restrictions actually in place on that field. It all goes horribly wrong when the receiving authority starts allowing "variants" and "common errors" and then discovers it can't tighten the validation back up again. Bitter experience :-)

Thank you

[venta.livejournal.com]

OK, that sounds like a low-effort professional approach :)

I'll have a look tomorrow at the PDF you linked to - it looked like it might take me a while to wade through it, so I figure I'll do it on work's time not my own.

(Tomorrow's other problem is to work out why efforts on my part to validate an example file against the schema fail with mysterious error messages :)